Stop hard-coding approvers into every workflow.

Use Roster to resolve the right user, group, role, or delegate at runtime — then let your existing workflow platform deliver and manage the task.

Build routing logic once and reuse it across automation systems, agentic workflows, and business processes.

Add Roster to a workflowExplore the Resolve API

One workflow. One pause point. One current participant.

Automation platforms are excellent at moving work forward. They are less good at knowing who should touch it next. Roster owns a single resolve() step — before your engine assigns, notifies, escalates, or hands off.

01
on: event
Trigger
02
enrich(ctx)
Prepare context
resolve()
Ask Roster who
roster
04
assign(user)
Assign task
05
notify()
Notify
06
close(case)
Complete
This is the only step Roster owns. The rest stays in your workflow engine.

Every engine, the same call

Whatever runtime you already operate, Roster is a single HTTP or MCP call away. The rest of the workflow keeps its native shape — HTTP nodes, service tasks, approval connectors, subflows.

n8n
workflow · HTTP node
Trigger
Set
resolve()
Wait for approval
Send email
Microsoft Power Automate
cloud flow
Trigger
Get item
resolve()
Start approval
Update record
Camunda
BPMN process · service task
Start
Enrich
resolve()
User task
End
Workato
recipe step
Trigger
Lookup
resolve()
Send for approval
Post
ServiceNow Flow
action · REST step
Trigger
Get record
resolve()
Ask for approval
Update

// one routing model — many engines · REST + MCP + CLI

Before Roster / After Roster

Same procurement workflow. Two very different maintenance stories — as roles change, people leave, and coverage shifts.

workflow.yml — hard-coded
brittle
Approvers baked into the workflow
01
steps:
02
- trigger: vendor_review_requested
03
- approve:
04
to: "sarah.chen@acme.com"
left the team 4 months ago
05
- notify:
06
cc: "eu-procurement-approvers@acme.com"
group renamed after reorg
07
- escalate:
08
after_days: 3
09
to: "marc.dubois@acme.com"
currently on parental leave
workflow.yml — resolved at runtime
resolved at runtime
Roster answers who — every time
01
steps:
02
- trigger: vendor_review_requested
03
- approve:
04
to: );font-weight:600">resolve("vendor.approver", ctx)
05
- notify:
06
cc: );font-weight:600">resolve("procurement.group", ctx)
07
- escalate:
08
after_days: 3
09
to: );font-weight:600">resolve("vendor.escalation", ctx)
what resolve() evaluates
projectregionthresholdroledelegationcoverage

Delegation without touching the workflow

When an active participant hands off responsibility, the workflow definition doesn't change. Roster changes its answer — with the trail back to the original owner preserved.

Mon · Aug 04
Alice
Current approver for EU vendor reviews.
Thu · Aug 07
Alice → Bob
Alice delegates during PTO. Nothing else changes.
Fri · Aug 08
Workflow triggers
€12k vendor review enters the procurement flow.
Fri · Aug 08
resolve() → Bob
Same call, current answer. Trail back to Alice is preserved.

The workflow YAML you shipped in April keeps running. The organizational reality is what moves.

Common workflow use cases

01
Procurement

Route each vendor review to the right procurement, finance, security, or legal approver based on project and request context.

resolves →vendor.approver
02
Customer onboarding

Send work to the current account owner, implementation lead, regional team, or delegated contact — not last quarter's owner.

resolves →account.owner
03
Security & compliance

Determine which participant should review a policy exception, access request, vendor, or data-processing action.

resolves →policy.reviewer
04
Employee operations

Use directory or Workday context to route HR, payroll, management, or employee-service requests.

resolves →manager.of(user)
05
IT & engineering

Resolve release approvers, service owners, change reviewers, and escalation contacts.

resolves →service.owner
06
Agentic human handoffs

Let an agent determine which human should review or approve before it executes a sensitive action.

resolves →human.gate

One routing model across every workflow engine you run

The same Roster participant can serve an AI agent, an n8n workflow, a Power Automate flow, a Camunda process, a CI pipeline, a custom application, and a human — so every automation team stops maintaining its own version of organizational responsibility.

Frequently asked questions

No. Roster resolves who should act. Your workflow engine remains responsible for orchestration, task delivery, decisions, and state.

Keep the process in your workflow engine — and the “who” in Roster.

Resolve current organizational responsibility without copying it into every automation.

Add Roster to a workflowExplore the Resolve APIExplore all solutions