What is business process automation?

Business processes cross departments, and that is where they slow down. An expense claim touches the employee, a manager, finance and the payroll system; a new supplier touches procurement, legal, finance and the vendor master. Each hand-off is a chance for work to wait in an inbox. BPA treats the process as one unit, so the automation follows the work across those boundaries instead of fixing one team's step and leaving the queue in the next.

It also forces a useful discipline. You cannot automate a process nobody has written down, so BPA projects usually begin by agreeing the steps, the owners and the exceptions. That agreement is often worth having on its own.

A BPA design starts from a process map: the trigger, the ordered steps, who or what does each step, the decisions and the exceptions. Each step is then assigned to a mechanism. A system-to-system step becomes an API call or a connector. A rule-based check becomes a condition in the flow. A judgement call goes to a person, or in newer designs to an AI model with a person reviewing the result.

An orchestration engine runs the process. It keeps the state of each case (which step it is on, what data it has collected, who it is waiting for), so a process that takes days survives restarts and holidays. Tasks for people appear in a queue or as an approval request, and the case moves on when they act.

Finally, the engine records each case. Because every case runs through the same path, you can see where cases wait longest, which exceptions recur and which step fails, and you change the process definition rather than retraining everyone.

An invoice arrives by email. The process extracts the supplier, amount, invoice number and purchase order reference, then matches them against the purchase order and the goods receipt in the finance system. If all three agree and the amount is within the agreed limit, the process creates the payable record and schedules payment.

If they disagree, the process routes the invoice to the budget holder with the mismatch shown side by side. The budget holder approves, rejects or asks the supplier for a corrected invoice, and the process records who decided what. Any invoice from a supplier whose bank details changed recently goes to a second person before payment, whatever the amount. The finance team sees one list of open cases instead of a shared mailbox.

Studio is built for this shape of work. A workflow holds the fixed steps, an agent can handle the step that needs reading a document and deciding what it is, and an approval step pauses the run until a named person approves. Each run is traced with logs and token-cost telemetry per step, so the record of a case exists by default.

Two honest limits. Approvals live in several parts of the Swfte platform and are not one unified inbox yet. Separation of duties is not enforced by the platform today: you enforce it by choosing who is assigned to each approval step. Studio also drives tools and APIs, not desktop screens, so a step that only works through an old application's interface needs a different tool.

• Swfte Studio
• Governed workflows
• How to set up human approval

Definitions on this page were read on the sources below on 7 October 2026. Where sources define the term differently, the page says so. The full glossary lists more terms.