Process Orchestration
Define and run business decision paths: gather evidence, route work, execute authorized steps, keep human approval gates, and review performance.
Compose business processes from reusable steps, route outcomes, keep approval gates explicit, and inspect execution and its results.
The Orchestrator is HEPO's software for executing a defined business process. A process owner establishes the work, decisions, and authority involved; an implementer connects the required capabilities into steps. The orchestrator runs those steps, follows their outcomes, and brings work to a person when the definition requires a human decision.
Its output is both the result of the work and a record of the path taken. A quotation can move through checks and approval, while the responsible team can inspect which steps ran, where an exception arose, and what should happen next.
A logistics company receives a shipping quotation. Sales needs a margin assessment, operations needs the vessel schedule, compliance needs the relevant trade information, and finance needs the customer's credit position. These are different questions with different sources and decision owners.
An implementer can compose a process that gathers the agreed information, performs suitable calculations, prepares material for review, and routes the case to the authorized approver. Independent checks can run together; a check that depends on another result must wait for it. The approval step determines the permitted next path.
Where the chosen connector supports it, an explicitly authorized integration step can send the resulting decision to the external system. A response can then open the relevant case or refresh the operator's view. This is a configuration example, not a packaged quotation service or a promised completion time.
HEPO calls these concerns its three rails. They explain how the process is assembled and governed:
| Concern | What the implementer establishes |
|---|---|
| Objects: available capabilities | Registered workers, validators, flow controllers, rules, and presentation components that a process can use |
| Processes: the path through work | Steps, inputs, dependencies, transitions, error paths, and reusable sub-processes |
| Permissions: the authority to act | Access to the process, its steps, relevant records, and protected fields |
A worker performs a unit of business logic. A flow controller, called a scenarist, selects the next step from the outcome and process state. That routing responsibility is distinct from a person's authority to approve a business decision. Security Follows the Actor explains how identity and permission belong in the path.
The coordinator's Observe, Orient, Decide, Act cycle gives the technical evaluator a way to follow execution:
Results distinguish success from structured failure. Step outcomes describe such possibilities as proceeding, branching, skipping, terminating, or redirecting. The implementer must account for the intended outcomes and exception paths; a diagram alone does not establish that every business case has been handled.
The visual design surfaces let an implementer connect steps and examine their inputs and outputs. Typed ports express what a connection carries: a value, a dataset, a time series, a condition, or another defined payload. Compatibility checks and declared column schemas help identify unsuitable connections before use.
The available building blocks cover data access, transformation, analysis, presentation, integration, and control flow. Human gates provide places for approval, review, or data entry. The actual process uses the registered workers and configured bindings available in the deployment.
For graph execution, dependency levels determine which steps can run together. Independent steps receive the state available at the beginning of their level, and successful results are merged afterwards. A failure is recorded without simply cancelling every sibling. This makes dependencies and failure handling part of the process design, rather than something inferred from the order in which boxes were drawn.
An agentic worker adds model and tool access to a worker's responsibilities. In the quotation example it might prepare a risk summary from selected records. Its result still belongs to a process step with an output and a failure path. Local inference supplies reasoning; it does not replace the approval authority or make the summary automatically correct.
The implementer establishes the model, tools, permitted inputs, and unavailable-service behavior. The reviewer receives the material needed to assess the result. The HEPO Assistant provides another way for a user to reach available work; it is not the flow controller itself.
Use validation and a configured simulation run to inspect bindings, dependencies, results, and simulated actions. A simulation requires an explicit treatment of side effects and suitable inputs. It does not automatically predict a team's future throughput. Process Analytics explains the distinction between execution records, review, and rehearsal.
Your process owner supplies the decisions and operating context. Implementers compose and verify the path; the delivery partner supports rollout and review with the people who will use it.
See the evidence behind the process ? See how results reach the user ? Process Orchestration overview
Bring us a process with its inputs, decisions, and expected result.