System Layer — Shared Services Behind HEPO
Understand HEPO's shared security, data, integration, local AI, workspace, and extension services, and how to evaluate them in your deployment.
Security: identity, authority, and accountable operations
Understand roles, permissions, client and server responsibilities, execution context, and audit review across HEPO.
Understand roles, permissions, client and server responsibilities, execution context, and audit review across HEPO.
HEPO's security architecture connects identity and authority to the information and operations available in the platform. Administrators maintain roles, permissions, and relevant scope. Application controls guide users toward permitted actions, while server enforcement is responsible for protecting the operation and its data.
This is a shared System Layer responsibility beneath all three offerings. A useful evaluation follows a real request through its interface, server operation, and resulting record.
Distinguish the layers of a permitted action
| Concern | What it establishes |
|---|---|
| Identity and session | Who is participating and under which current context |
| Roles and permissions | Which operations and information that context permits |
| Interface behaviour | Which controls and information the application presents |
| Server enforcement | Whether the actual request is allowed |
| Audit and execution context | What can be examined afterwards about the request and result |
The architecture aims for a consistent access model across the application and server. A hidden control is not a substitute for server enforcement, and a common permission vocabulary does not by itself prove identical coverage on every path. Demonstrate both the presented interface and a disallowed operation at the server boundary.
Roles, permissions, and the relevant object
Role administration, permission trees, actor assignments, expressions, and topology views make access configuration inspectable. A role may permit a process without granting access to every record or field the process could encounter. The configured rules and implementation of that path determine the result.
The process security explanation follows process, step, object, and field access through a quotation. This page owns the shared model; that page applies it to execution and business decisions.
Keep confirmation, permission, and approval separate
An interface confirmation asks whether the user intends to invoke an action. Permission determines whether it is allowed. An approval records a business decision required by the workflow. A routine authorised operation can run automatically while a consequential decision waits for the designated reviewer.
User-initiated work, scheduled work, and external connector calls may have different execution identities. The organisation must establish the owner and permitted scope of each. An audit account should distinguish the initiating person, a reviewer, and the software or integration carrying out the authorised step.
Examine the audit account
The audit design provides records for reviewing activity and change. Evaluate which operations are covered, which actor and process context is retained, who may read the records, and how retention and integrity are administered.
Append-only application behaviour and protection against a privileged infrastructure change are different claims. The deployment's controls, backup arrangements, and operational responsibilities belong in the review. A queryable audit screen alone does not prove that every possible read or mutation is recorded.
Review with representative roles
Ask the implementer to demonstrate the same work under two roles, including a restricted field, a denied request, a changed permission, and a relevant audit record. Include delayed execution if the proposed workflow uses it. The organisation owns the authority model; implementers configure and verify it; security reviewers examine its actual effect.
Data Integrity, Deployment, and the Architecture & Security reference cover the related boundaries.