Follow the UI in the order an operator does
The workspace exposes Users, Service Accounts, Groups, and Permissions as distinct sidebar areas. That separation mirrors the model: first establish who or what executes, then give it platform roles, then grant access to a restricted Table, Storage folder, or other governed resource.Person
Use Users for interactive operators and their instance access lifecycle.
Workload
Use Service Accounts for Jobs, CI, server integrations, and Agents.
Boundary
Use Groups and Permissions to express resource membership and reusable platform roles separately.
Access model
RESOURCE_WRITE permits data changes only for a Table the principal can access, unless the principal has the corresponding administrative authority.
Identity types
Use separate service accounts for systems with different blast radius or ownership. Do not run production automation under a developer’s personal identity.
Users
Open Users to invite, inspect, update, activate, disable, restore, or delete human accounts. User administration and platform access are separate lifecycle decisions.- Disable account blocks the user for the current tenant lifecycle while preserving recoverable account state.
- Disable platform access removes access to the RevoEngine workspace without treating the account record as deleted.
- Delete is the permanent account lifecycle boundary.
- Restore / activate re-enables an eligible account after an administrator reviews roles and group membership.
Service accounts
Open Service Accounts to create a non-human principal, assign ownership metadata, attach permissions, and manage its API keys. A good service account has:- one clear workload or system owner;
- least-privilege role groups;
- explicit access to restricted resources it needs;
- short or reviewed API-key lifetime;
- a documented rotation and incident-revocation procedure.
Groups and permissions
RevoEngine distinguishes two group concepts:
Open Groups to manage membership used by resource ACLs. Open Permissions to compose reusable role sets and attach users.
This separation lets a finance team receive access to finance resources through a Group while only selected operators receive
RESOURCE_WRITE through a Permission group.
Role families
Most platform capabilities use read, write/runner, and admin or invoke roles:INSTANCE_ADMIN is intentionally broad. Prefer scoped role families for routine users and workloads.
Resource ACLs
Tables, Views, Storage entries, and other supported resources can be restricted to explicit users and Groups. Authorization uses current membership at request time. For hierarchical Storage, a restricted ancestor continues to constrain descendants. For automation, remember that the execution principal—not the person viewing the template—must pass the resource ACL.API keys
API keys belong to a user or service account and inherit that principal’s current access. A key is not an independent superuser. When creating a key:- Choose a descriptive workload name.
- Prefer a service account owner.
- Add an expiration date where practical.
- Restrict source IP, network, or range when the workload has stable egress.
- Store the value once in a secret manager.
- Test with the exact roles and resource ACLs used in production.
Human login and instance sessions
Human authentication begins with the configured identity provider. Enterprise instances can operate in SSO or HYBRID mode with approved SAML and OIDC/JWK providers. The instance policy determines which providers are accepted and whether eligible identities are automatically provisioned or require an administrator workflow. SSO is an identity boundary, not an authorization shortcut. A successfully authenticated person still needs enabled instance access, assigned roles/Permission groups, and any resource ACL membership required by the operation. Organization workspaces require multi-factor authentication and a registered browser before an instance-bound session is issued. The browser session is short-lived and bound to the account, selected instance, trusted device, and current security revision. The application refreshes it while the device and account remain eligible. Users can inspect and revoke trusted browsers. Revoking a device prevents future session refresh for that registration. Resetting multi-factor authentication invalidates prior device trust.Support access
Support is a distinct security mode, not a role that a normal session can self-select. It requires an eligible internal support identity, explicit assignment to the instance, multi-factor verification, and a time-limited grant. Support access never turns an API key or normal user session into a support session. Instance-bound HTTP and Realtime services validate that the session mode and request mode match.High-level backend mechanism
Global identity establishes who the caller is and which instances they may select. The instance control plane stores current account state, roles, permission groups, Groups, resource ACLs, and API-key records. Every governed execution establishes instance context before loading authorization and fails closed when identity state is incomplete. Authorization-relevant changes invalidate shared security state. Short session lifetimes and revision binding provide a hard backstop for already issued credentials.Access review checklist
- Separate human and workload identities.
- Use one service account per system or trust boundary.
- Assign roles through Permission groups where possible.
- Use Groups for restricted-resource membership.
- Review
INSTANCE_ADMINassignments frequently. - Expire and source-restrict API keys where practical.
- Disable an identity immediately during an incident; delete only at the intended lifecycle boundary.
- Revoke unrecognized trusted devices.
- Test automation with its real execution principal.
- Verify Realtime disconnect and HTTP denial after critical access changes.
Related guides
Users
Provision people and manage their lifecycle and memberships.
Service Accounts
Create workload identities and rotate their API keys.
Groups
Govern access to restricted resources.
Permissions
Compose reusable platform role sets.
Authentication
Authenticate Platform API and runtime requests.
Security and governance
Review the platform-wide security model.
Secrets
Store workload credentials outside source and configuration payloads.
API reference
Manage accounts, Groups, Permission groups, roles, and keys programmatically.