HEPO's process security connects work to the identity and authority under which it runs. For a user-initiated process, the caller's context belongs in permission checks and execution records. When a business decision requires a reviewer, that person's authority must remain distinguishable from the software carrying out the next step.

This gives the process owner and technical evaluator concrete questions to examine: who initiated the work, which actions and information were permitted, who decided, and what happened afterwards.

Follow authority through the quotation

Sales initiates a quotation review. Finance may need credit and pricing information, operations may need scheduling details, and another reviewer may need the applicable terms. The process definition brings their contributions together; the access design determines what each participant may see and change.

A successful calculation does not authorize an approval. A finance reviewer approving a quotation does not grant every other participant access to financial fields. The process must carry the appropriate context as it moves between steps and people.

Two users can therefore reach different permitted views or outcomes from the same process definition. The useful demonstration includes both an allowed action and a denied one, using representative roles.

Four levels of access

The architecture provides permission expressions and object checks to support those distinctions. Their effect depends on the process bindings, record access, field handling, and configured rules involved. The evaluator should inspect the actual path used by the proposed deployment.

Field access matters when a view contains information for several roles. Hiding a column on one screen is not sufficient evidence of a protected field; the permitted response and operation also need examination.

Distinguish confirmation, permission, and approval

Confirmation checks that a user intends to invoke an action. Permission establishes whether the action is allowed. A human approval gate records the business decision required to continue. One does not replace the others.

The assistant supports execute directives with a confirmation setting. Where confirmation is required, the user sees the proposed action before invocation. The process's human gates remain separate from that interface confirmation. A routine permitted step can execute automatically without turning a model's recommendation into an approved business decision.

The organization and implementer establish these boundaries for the specific workflow. Describe the actions that require a person, the actions already authorized by the process, and the exception path when authority is insufficient.

Guardrails and execution context

System rules can add blocking, audit, or additional-authorization behavior to a process. They give implementation another way to express conditions that matter across individual steps. Relevant masking and rule behavior must be included in the demonstrated path.

User-initiated work, scheduled triggers, and external connector calls also have different contexts. A connector may use credentials issued by another system. A schedule needs a defined owner and permitted execution scope. These arrangements should preserve accountability without pretending that every automated event is a fresh human approval.

For delayed work, establish how the deployment handles changed permissions, unavailable users, and expired decisions. That behavior deserves a specific review; an identity recorded at initiation alone does not prove every later authorization was reevaluated.

Examine the record as well as the result

The execution and audit information should let an authorized reviewer relate the initiator, relevant decision, process path, and outcome. In the quotation example, the reviewer's decision and confirmation of an outbound delivery are different events, and both matter to understanding completion.

The platform's audit design supports this accountability. Review the actual coverage, access, and retention of the configured deployment. The existence of an audit mechanism does not establish that every possible data access is recorded or that no privileged administrator could alter the surrounding infrastructure.

Local deployment and local inference help the organization control where processing occurs. Data Integration still involves agreed exchanges with external systems. State those connections explicitly when reviewing the boundary.

Questions for the demonstration

System Layer: Security explains the shared identity, permission, enforcement, and audit responsibilities. This Process page applies them to an actor's path through a decision.

Ask to follow the same case under two roles, including a restricted field and an unauthorized action. Inspect what the assistant proposes, where confirmation appears, and which process step waits for human approval. Examine the resulting trace, including an exception and any supported outbound delivery.

The process owner supplies the authority model. Implementers configure and verify the controls; security reviewers examine their actual effect; the delivery partner coordinates the demonstration and handover. That makes "security follows the actor" something the organization can assess in its own work.

The Orchestrator | The people-side trust explanation

Walk through one decision and its access boundaries with us.