Routing Rules

What routing means in this project

Routing in OrcaPulse is the part of the workflow that decides what should happen after a lead is captured or qualified. In the current project, routing is not a separate rules engine. It is expressed through ordered workflow steps and execution settings on the workflow itself.

That means a routing rule usually becomes a real sequence like: wait, send a message, trigger an AI call, sync to a CRM, send a webhook, or stop and wait for the next scheduler window.

Routing building blocks

The workflow model currently supports the core step types that routing depends on: SMS, email, WhatsApp, AI call, wait, CRM sync, and webhook sync. These are the downstream actions a qualified or newly captured lead can be routed into.

In the builder and execution service, routing stays grounded in real configured resources such as templates, assistants, phone numbers, CRM connections, and webhook targets.

Step order and wait/resume

Routing is order-dependent in the current backend. Workflow steps are sorted by their order value and executed in sequence. This is what determines the path a lead follows.

Wait steps are especially important because they pause execution, store the next step index on the lead metadata, and let the scheduler resume the workflow later. So a routing path can stretch across time instead of running everything immediately.

• Ordered execution: steps run in sequence based on the workflow step order.
• Wait support: wait steps move the lead back to a pending state until the scheduled resume time.
• Resume tracking: workflow step index and wait metadata are stored so execution can continue from the right place.
• Practical effect: routing can support fast first response, delayed follow-up, and staged downstream sync.

Timing and duplicate protection

Workflow-level settings shape routing before any individual step executes. Execution delay, day and night mode, day start and end hours, and duplicate protection all change how and when a lead actually moves into the next action.

Duplicate protection matters because routing should not keep advancing the same lead through repeated downstream actions if the product has already identified the lead as an existing record.

• Execution delay: spaces out the first action after a lead is scheduled.
• Day and night mode: pushes execution into allowed business-hour windows when enabled.
• Duplicate protection: helps block repeated processing when the workflow is configured to prevent duplicates.
• Recall settings: add controlled retries for workflows that need repeated contact attempts.

Execution outcomes and visibility

Routing is observable in the current project. Leads carry execution state, scheduled times, recall status, and the latest call metadata. Timeline events are added as actions start, pause, succeed, fail, or time out.

This gives teams a practical way to inspect whether a routing rule actually did what it was supposed to do after qualification.

• Lead state: execution status moves through pending, executing, in progress, completed, or failed.
• Timeline history: records waits, sends, call starts, sync attempts, and failures.
• Call-aware routing: AI call steps can keep the lead in progress until the call outcome is known.
• Operational review: Lead Hub and lead review surfaces help teams understand where a routed lead ended up.

How to design the first routing rules

The best first routing setup in this project is usually narrow and explicit. Start with one clear path from qualification into the next action instead of trying to model every exception on day one.

A simple rule might route a qualified lead into a wait step, then a WhatsApp or SMS follow-up, then a CRM sync, while a higher-priority path might hand the lead to AI calling first.

• Keep the path short: one to three downstream actions are easier to test than a long chain.
• Place waits intentionally: only add pauses where timing actually changes outcome quality.
• Sync late or sync early on purpose: decide whether CRM and webhook steps should happen before outreach, after outreach, or after call review.
• Validate resources first: routing only works when templates, assistants, numbers, CRM connections, and webhooks are already configured.

Next steps

Once routing is stable, the next layer is deciding when OrcaPulse should escalate to human review, continue automated follow-up, or hand a lead into longer-running automation paths.

Keep the first routing rules easy to inspect, confirm the timeline shows the expected path, and then expand into human handoff, follow-up automation, and richer multi-step orchestration.