Core product

Inbox and Routing

Visit websiteOpen portal

This page documents the operational inbox and routing surfaces in the current OrcaPulse project: social conversations, WhatsApp conversations, workflow assignment, manual reply and takeover controls, and the review layers teams use to understand where each lead or conversation should go next.

What inbox and routing mean here

Inbox and routing in OrcaPulse are the operational layers where conversations are reviewed, acted on, and connected to workflow execution. This is where the product stops being only a background automation engine and becomes a working surface for day-to-day lead operations.

In the current project, this includes social inbox-style conversations, WhatsApp conversation threads, lead review surfaces, and workflow-assignment visibility that shows where a conversation has been routed.

Conversation surfaces in the project

The product already has multiple inbox-like surfaces. Social media controllers expose conversation listing, single-conversation detail, manual reply, takeover, release, read state, and deletion. WhatsApp has its own inbox flow with per-account conversations and message history.

These are not generic placeholders. They are concrete operating views built around real conversation history and message threads.

Social inbox

Social conversation routes already support listing conversations, viewing history, sending manual replies, takeover, release, and read-state changes.

WhatsApp inbox

The WhatsApp inbox groups messages by conversation ID, loads per-account threads, supports read state, delete, and direct sending from the conversation view.

Lead review

Lead Hub and Review Leads connect conversation handling to workflow assignment, execution state, follow-up status, and timeline review.

Workflow assignment and routing visibility

Routing becomes visible in the inbox when a captured or converted record is assigned to a workflow. Social leads already store assigned workflow references, and timeline events are added when the record is routed into a workflow path.

Lead Hub and Review Leads extend that visibility. They connect the conversation layer to execution status, scheduled actions, call outcomes, and the overall workflow path the lead is following.

  • Assignment visibility: social leads can show which workflow they were routed into.
  • Timeline support: assignment and later execution events make routing inspectable after the fact.
  • Lead review linkage: Lead Hub and Review Leads connect inbox activity to execution and follow-up state.
  • Operational clarity: teams can see not just the conversation, but also what system path the conversation triggered.

Operator actions inside the inbox

The inbox is not passive. Operators can already intervene directly in several ways: send manual replies, take over a social conversation, release it back to AI, mark a conversation as read, delete threads, or move into lead review and workflow-level control if the conversation has already progressed.

This is important because routing and inbox work together. A conversation can be AI-led, human-led, workflow-led, or paused, and the inbox gives the operator a place to decide which mode should apply.

Current project pattern: capture the conversation, keep the thread visible, route it into a workflow when appropriate, and still allow operators to step in with manual actions when the conversation should not be left to automation alone.
  • Manual reply: answer directly from the conversation surface while preserving history.
  • Takeover and release: switch between human control and AI-led conversation handling.
  • Read-state management: use inbox status to reduce noise and track what still needs attention.
  • Escalation path: move from inbox review into Lead Hub, Review Leads, or manual workflow control when needed.

WhatsApp and social inbox views

The social inbox and WhatsApp inbox are related but not identical. Social conversations are stored on social lead records with conversation history and platform context. WhatsApp conversations are grouped around conversation IDs and message history tied to a selected account.

Together, these views show the broader OrcaPulse pattern: channel-specific inbox handling on the front end, with routing, review, and automation layered on top.

  • Social view: best for DM-style capture, AI conversation handling, and workflow assignment on social leads.
  • WhatsApp view: best for account-scoped message threads, unread counts, and direct thread response.
  • Shared principle: both views preserve conversation context instead of flattening everything into one abstract lead row.

How to design the operating flow

The best inbox and routing setup in this project is one where operators can quickly tell which conversations need human attention, which ones are already safely routed into workflows, and which ones should stay channel-native for a little longer.

Keep the first operating flow simple: define when a conversation stays in the inbox, when it should be assigned to a workflow, and when the team should jump into Review Leads or Lead Hub instead of replying in-thread.

  • Separate triage from execution: use the inbox for thread handling and review surfaces for workflow-level decisions.
  • Define assignment moments: make it clear when a conversation becomes a workflow-managed lead.
  • Preserve context: keep conversation history visible so routing decisions are understandable later.
  • Avoid duplicated work: make sure the team knows when to reply in the inbox versus when to act in the lead workflow view.

Next steps

The core product documentation set is now covering capture, qualification, routing, handoff, follow-up, agentic behavior, and inbox operations. From here, the next pages can move into channels and integrations in more depth.

A natural next step is channel-specific documentation such as Instagram or WhatsApp.