Triggers & eligibility
Start work from a supported conversation or business event. Check the relevant conditions and exclusions before assigning the role.
Example: a qualified enquiry starts sales outreach.
WORKFORCE ORCHESTRATION
Orchestration in UnleashX is how several AI employees hand one piece of work between them, sharing context so each step starts from what the last one actually did. Give each role ownership of its work. Connect employees, tools and business events through shared context, explicit routing and verified outcomes, with people joining for exceptions, not every routine step.
A STATE-AWARE WORKFLOW
Watch Peter’s sales workflow connect to Meera’s onboarding role. A verified customer event, not a booked meeting, opens the next stage. Inspect the commercial-exception branch to see the human handoff.
SHARED WORK RECORD · LEAD-208
Owner: Peter · Context: Lead context + contact preferences

Qualify · answer · book
Confirmed customer event?
Wait for source-system evidence
Waiting · no onboarding yet
Joins only for commercial exceptions. Routine actions do not need repeated approval.
AUTONOMOUS WORK
An eligible prospect enquiry starts Peter’s sales workflow.
ACTION HISTORY
01Assign owner
Step 1 of 4 · Assign owner
WORKFORCE DESIGN
Orchestration determines what happens next, who owns it and when the process can continue. Integration supplies the system connection; orchestration applies it within the job.
Start work from a supported conversation or business event. Check the relevant conditions and exclusions before assigning the role.
Example: a qualified enquiry starts sales outreach.
Assign one accountable owner to the current responsibility. Give each employee a coherent job and a clear output rather than overlapping instructions.
Example: Peter owns qualification; Meera owns onboarding.
Carry source references, captured intent, completed actions and unresolved questions with the task. Context should survive a role or channel change.
Example: the account record carries the verified customer event.
Advance when the completion criteria are supported by evidence. Route incomplete work to clarification, recovery or a human decision instead of forcing a success path.
Example: onboarding waits until the customer state is confirmed.
Reserve exceptions and higher-authority decisions for named people. The handoff explains what was done, what remains unresolved and what decision is needed.
Example: a commercial exception goes to an authorized seller.
Evaluate the complete process as well as individual roles. Retest routing, action verification and handoff behavior when knowledge, permissions or tools change.
Example: a new offer rule is tested before release.
CONTEXT THAT TRAVELS WITH THE WORK
| Record element | Why it matters | Example |
|---|---|---|
| Source references | Keep the task tied to authoritative business records. | Lead, account and appointment references. |
| Current state & owner | Make waiting, active and exception states visible. | Waiting for confirmed customer event; no onboarding yet. |
| Completed actions | Avoid repeating work or reporting an unverified result. | Qualification saved; calendar booking confirmed. |
| Decision needed | Give people a concrete reason to intervene. | Review a non-standard commercial request. |
| Next trigger | Explain what evidence allows the work to resume. | A verified account event or recorded human decision. |
Agree the exact fields, permissions and evidence for your workflow. Examples illustrate a design; they do not imply native availability for every system or a measured performance result.
DESIGN THE EXCEPTIONS
Autonomous execution includes knowing when the configured action cannot safely continue. Keep the work visible and give the next owner enough context to recover it.
Keep the task in a waiting state with an owner and a defined follow-up policy. Do not infer that a sale, payment or approval occurred from an earlier conversation.
Route the affected operation to reconciliation. Preserve the context and completed work; do not restart the entire journey or blindly duplicate the action.
Pause the affected action and attach the request, records and history to the handoff. Define who records the decision and what permits the workflow to resume.
BEFORE PRODUCTION
Start with one representative process and its difficult cases. Set the acceptance criteria before testing, then review the final records and ownership with business and technical teams.
Choose the business outcome, initial trigger and completion criteria. Identify normal waiting states and events outside the employee’s control.
Outcome and state mapGive each role its responsibility, inputs, tools and handoff contract. Use fewer roles when one employee can own the job cleanly.
Role and authority mapDefine when to continue, clarify, wait, recover or escalate. Specify what evidence is needed before moving to the next owner.
Routing and recovery rulesTest the full journey, including late events, missing context and tool failures. Review final system states and human handoff quality together.
End-to-end acceptance recordBUYER & TECHNICAL QUESTIONS
It is the operating logic that connects role ownership, business events, system actions and human decisions around a shared outcome. It defines what runs next, what context travels with the task and which evidence proves a step is complete.
Integrations let the employee read or change a connected system. Orchestration decides when that operation is needed, which role owns it, how its result changes the workflow and what happens if it fails or requires a person.
Not always. Use one role when the job has a coherent responsibility and authority boundary. Separate roles when that improves ownership, permissions or workflow clarity. More agents do not automatically create a better process.
Yes. Within configured rules, employees execute routine work autonomously. People handle exceptions and decisions outside authority. Define that boundary before release so escalation is deliberate rather than a default approval at every step.
Specify the task or business record that carries source references, customer intent, completed actions and unresolved questions. Confirm how this is implemented in your environment. A shared record does not mean unrestricted access to all customer data.
Design waiting states around the events your implementation can reliably observe. Define event matching, ownership and what happens if the event never arrives. Confirm the supported event or polling mechanism rather than assuming a particular runtime behavior.
The assigned person receives the case context and required decision. Define how their response is recorded and what evidence allows the affected workflow to resume. Do not interpret a notification being sent as an approval being granted.
Test the normal path, unclear inputs, failed writes, late events and decisions outside scope. Review ownership, state transitions, final records and handoff packets. Measure business completion separately from conversation quality or the number of actions attempted.
BRING ONE REAL WORKFLOW
Share the trigger, roles, system actions and exceptions. We’ll define ownership and the evidence that moves the work to its next stage.