Process-driven UI: connect work to registered interfaces

Use registered screens and navigation paths to bring the relevant interface into a process or assistant interaction.

Use registered screens and navigation paths to bring the relevant interface into a process or assistant interaction.

Process-driven UI describes HEPO's use of registered interfaces as part of carrying work to the user. A process or assistant can address a supported screen or pane through its registered path, with the relevant record and context. The user receives an interface connected to the work being performed.

The original principle is that screens can be appended to processes. It makes the interface binding an explicit part of designing the workflow, alongside the steps, decisions, and operations.

Bring a review to the responsible person

A quotation reaches a point where a reviewer needs to inspect information and decide. The configured flow identifies the appropriate registered interface and the context it should receive. The user can then inspect the relevant records and carry out the permitted action.

The interface presents the task; the process and security configuration determine what the action means and whether it may proceed. Opening an approval screen does not itself approve the quotation.

Registered interfaces make the binding explicit

Concern What the design identifies
Process step The work or decision that needs an interface
Registered surface The supported screen, pane, or view to address
Context and payload The subject and information needed by that surface
Navigation mode How the view appears in the application or Common Canvas
Permitted action The operation the user can invoke from that context
Result and continuation What the process does after the action or an exception

The shared navigation path supports human, assistant, and orchestrator sources. Registered views can be opened or focused where their presentation mode is supported. A normal route remains the fallback for a surface that is not available in the current canvas.

Keep execution, navigation, and approval distinct

The Orchestrator owns process execution and its step behaviour. Common Canvas owns workspace composition. The HEPO Assistant uses supported directives and actions. This page owns how the work identifies the interface the user needs.

A process change may reuse an existing registered surface, reducing duplicate screen work. A new field, interaction, or decision can still require interface development and testing. Registration makes the binding explicit; it does not guarantee that process and screen versions can never diverge.

Walk a change through both sides

The process owner describes the decision and information required. Implementers bind the supported interfaces and operations, including errors, cancellation, and insufficient authority. Technical reviewers inspect a normal path and an exception path.

A useful demonstration changes one review step and follows its effect on navigation, presented data, permitted action, and continuation. That shows how the interface follows the work while preserving the responsibilities of the user and the executing process.

System Layer | Platform overview