Technology
Workflow Orchestration
Steps, queues, approvals and integrations as a modelled process, run and audited by the engine.
The concept
The process around the agents
Who has to act, by when, in what order, and what happens when they do not. The agents inside its steps are coordinated by AI orchestration.
A finance process is more than a run of machine steps. An invoice waits in a queue for an analyst. An approver has a deadline, and then goes on leave. A supplier has to send a credit note before anything can move. The ERP stops accepting postings on the last evening of the month. Workflow orchestration is the engine that models all of that: steps, queues, owners, clocks, approval routes, escalation paths and the integrations that write the outcome into your systems. It holds the state of every case and knows what each one is waiting for.
The process is a model with a version. Each workflow is a definition of its steps, which of them need a person, which band routes to whom, how long each step may take and where it escalates. Changing the definition creates a new version, approved and dated the way a rule change is. Cases already in flight finish on the version they started on unless someone with the right role moves them, so a policy change on the fifteenth leaves the routing of the tenth as it was.
This is a different job from coordinating agents, and keeping the two apart keeps both readable. The AI orchestrator works in seconds: which agent runs next, what it is given, which tools it may call. The workflow engine works in hours and days, across people and systems. When an agent needs a person, the item crosses from one to the other and back, on the same record. A CFO asking why an invoice took four days reads the workflow history. An architect asking why an agent matched the wrong PO line reads the orchestration trace.
Where it sits
The workflow engine across the five stages
PTAS AI workflows run as Perception, Intelligence, Orchestration, Action and Verification. The workflow engine owns the business side of orchestration and most of action.
Two orchestrators
Workflow orchestration and AI orchestration, side by side
The same invoice, seen by both engines at the same moment. The right-hand panel is this page. The left-hand panel is AI Orchestration. Values are illustrative.
One invoice, two orchestrators. Illustrative example
If the question is which agent runs next and what it may touch, that is AI orchestration. If it is who has to act and by when, that is workflow orchestration.
Clocks belong to the workflow
Deadlines, pauses and escalation run in the engine, never inside an agent.
Agents are called, then waited on
A step that needs an agent hands over to the AI orchestrator and gets a result back.
One record for both
The case history and the agent trace sit on the same item.
In the products
What the engine runs inside FinSuite and DocPro
Most of the workflow in FinSuite is approvals, exceptions and payment. In DocPro it is review and delivery.
FinSuite
Approval routing
Value bands, cost centres and entities decide the route. Delegation applies while an approver is away, and the decision records who acted under whose authority.
FinSuite
Exception queues by cause
Price variances, missing GRNs, tax mismatches and new-vendor holds land in separate queues with their own owners, so the person who can fix the cause is the one who sees it.
FinSuite
Payment runs and cut-offs
A maker prepares the run, a checker releases it, and the cut-off is enforced by the engine instead of remembered. Status comes back to each invoice once the run is released.
FinSuite
Waiting on the outside world
A case that needs a credit note or a corrected GSTIN from a supplier pauses its clock and resumes when the document arrives. The wait is recorded against the supplier.
DocPro
Review as a step with a clock
A field below threshold opens a review task with an owner and a time limit, and the document's later steps wait for it. Time spent in review is measured like any other step.
DocPro
Delivery to your systems
Completed records go out by API, webhook, file or into FinSuite. A delivery that fails is retried, and one that keeps failing is raised to a named owner. Nothing is dropped silently.
Worked example
One price variance from case to posting
A supplier invoice that broke the price tolerance, followed through the engine for twenty-six hours. Then the approval route the same invoice walked, delegation included. Values are illustrative.
One price variance, case to posting. Illustrative example
The clock paused while the supplier held the case, so the escalation measured your team's time and nobody else's.
Escalation by the clock
Nobody chased the case. At eight hours it moved to the named cover on its own.
Waiting is recorded too
The eleven hours with the supplier are on the case, against the supplier.
One posting, after a retry
The ERP timed out once. The retry carried the same key, so one document was created.
Once the variance was settled, the invoice still needed approval by value band. The route below is read from the approval policy as configured. The approver named for the band was on leave, so the delegation in force that day applied, and the record shows under whose authority the cover acted.
Invoice ₹ 2,70,220 — the route it took · Illustrative example
Nobody shared a login and nobody chased by email. The delegation, the timestamp and the reason are all on the entry.
Limits and controls
What a workflow engine cannot decide for you
The engine runs the process you define, and it runs it exactly. If the approval matrix still names someone who left in March, the engine routes to them until the matrix changes, and escalation is what catches it. A queue with no owner produces cases nobody sees. A time limit set shorter than the work takes produces escalations, and too many of them teach people to ignore escalations. These are design problems. The first weeks of a rollout tend to surface them, so we review queue ages and escalation counts with the process owner in that period and change the definition through the same versioned change as any other.
The engine also depends on the systems it writes to. When the ERP is unavailable, postings wait and retry; they do not go somewhere else. The controls below exist because of those limits.
Versioned process definitions
Steps, routes, clocks and escalation paths are a definition with a version, an approver and an effective date. Cases in flight keep the version they started on.
Clocks that pause and escalate
Each step has a time limit you set. Waiting on a supplier pauses it; running out moves the case to the next name, and the wait is recorded against the step.
Segregation of duties
Whoever raised or coded a case cannot approve it, and the approver cannot release the payment. Roles are checked at each step.
Writes that happen once
Postings and payment files are sent with a key, retried on timeout and counted as done only when the receiving system confirms. A retry cannot create a second document.
The bands and tolerances the engine reads are described under Business Rules. What a reviewer sees when a case reaches them is under Human-in-the-Loop.
FAQ
Questions architects ask about workflow orchestration
How is workflow orchestration different from AI orchestration?
Workflow orchestration runs the business process: which person or system acts next, by when, in what order, and what happens when nobody does. It works in hours and days, across people and systems. AI orchestration coordinates the agents and models inside the steps that need them: which agent runs, what it is given, which tools it may call. When a workflow step needs reading or matching, it calls the AI orchestrator and waits for the result. Both write to the same record.
What happens to cases in flight when we change the approval matrix?
They finish on the version of the workflow they started on, unless someone with the right role moves them to the new one, and that move is recorded as an event of its own. New cases use the new version from its effective date. A policy change on the fifteenth does not rewrite how a case was routed on the tenth, and the record of the tenth still shows the old route.
Does this replace the approval workflow in our ERP?
Not necessarily. Your ERP stays the system of record. The engine runs the steps around the posting: capture, checks, exceptions, approvals and the posting itself. Where your ERP already runs an approval you want to keep, the workflow hands over at that point and reads the result back. Which approach fits is decided per process during the assessment.
What happens when the ERP or another system is unavailable?
Steps that write to it wait and retry with a pause between attempts, each carrying the same key so a late success cannot be duplicated. If the system stays unavailable past the limit you set, the affected cases are raised to a named owner with the step and the error shown. Nothing is posted anywhere else in the meantime, and a step counts as done only when the receiving system confirms it.
Keep reading
Where workflow orchestration connects
AI Orchestration
The other engine: how agents and models are coordinated inside a step.
Read more →Workflow Automation
The capability view: approval routing, payment release and onboarding as governed processes.
Read more →Business Rules
The bands, tolerances and checks the workflow reads at each step.
Read more →FinSuite AP Automation
Exception queues, approvals and posting in the payables module.
Read more →Next step
Model one process before you automate it
Bring the approval matrix and the exception list for one workflow. We will lay out the queues, owners, clocks and escalation paths, and show where the agents sit inside it.