Skip to main content
Service Accounts are non-human principals. Use them whenever RevoEngine or an external system must act without an interactive person: scheduled Jobs, CI/CD, server integrations, durable Agents, and API clients.

​
Create a workload identity

Open Service Accounts, select Add, and configure: The platform creates the account email/identifier; it is displayed as read-only after creation. Reopen the account to assign Groups, Permission groups, and API keys. Ownership is accountability metadata—it does not automatically grant the owner the service account’s runtime permissions.

​
Design one account per trust boundary

Do not share one service account across unrelated systems. Separate identities let you rotate or disable one integration without stopping every workload.
Use metadata such as environment, system, ownerTeam, and rotationPolicy for discovery. Never store the key value itself in metadata.

​
Grant access

  1. Add the account to a Permission group containing only the required platform roles.
  2. Add it to Groups used by restricted Tables, Views, or Storage folders.
  3. Test the exact API or automation operation.
  4. Remove any temporary administrative access used during setup.
The account executing a Job or integration is re-evaluated at runtime. A template created by an administrator does not inherit administrator access.

​
API keys

Open a saved Service Account and select API Keys. Create a key for one client or deployment, store the value once in a secret manager, and record its owner and rotation date.
Keys inherit the account’s current status, platform roles, Permission groups, and resource ACLs. Disabling the account invalidates admission without requiring every key row to be deleted first.
Never paste a key into Component source, metadata, Job input, Chat, Assistant, screenshots, or documentation. Resolve it from an approved secret manager or RevoEngine Secrets.

​
Lifecycle and roles

The UI supports save, API-key management, activate, disable, enable/disable platform access, delete, and restore. Disable immediately when ownership is unclear or a credential may be exposed. Before permanent deletion, move any Jobs, Schedules, Agents, and external clients to a replacement principal.

​
Rotation runbook

  1. Create a new key for the same Service Account.
  2. Deploy it to the consumer’s secret store.
  3. Verify a real authenticated request and expected ACL behavior.
  4. Revoke the old key.
  5. Monitor authorization failures and workload status.
  6. Record the new rotation date without recording the key value.

​
Production checklist

  • One account per system, environment, or trust boundary.
  • Explicit human or Group owner.
  • Least-privilege Permission groups.
  • Explicit membership for restricted resources.
  • Separate keys per client deployment.
  • Documented rotation and emergency-disable procedure.
  • No unattended automation under a user identity.
See Permissions, Groups, and Secrets.
Last modified on September 5, 2026