Skip to main content

​
Overview

Aptly uses a hybrid authorization model:
  1. Roles (RBAC) – grant modules and actions (view, create, approve, manage, revoke)
  2. Scopes – tenant-wide or limited to specific Groups (dept, entity, region, etc.)
  3. Fine-Grained Authorization (FGA/ABAC) – evaluates user attributes and capacities on each record (e.g., Owner, Issuer, Recipient, Role Designee) and group membership from your directory/HRIS.
Effective access is the intersection of these layers: the user must have the role permission (with applicable scope) and, when relevant, the record capacity / share / group relationship that the policy requires.

​
How access is evaluated

  1. Module access: Can the user enter the module? (Decisions, Delegations, Matrices, Documents, Actions, Reports, Settings)
  2. Permission + scope: Does the role grant the needed action (e.g., approve_delegations) at tenant level or within the assigned Groups?
  3. Record capacity / sharing: For many actions, users must also be an Owner, Issuer, Recipient, Role Designee, or part of a shared user/group on the record.
  4. Inheritance: Certain capabilities propagate from tenant → group → record (e.g., viewing group delegations enables viewing specific delegations owned by that group).
Example: Approving a redelegation may require approve_delegations and being an Issuer on the parent delegation (or having the required group relationship), per policy.

​
Default roles (non-editable)

Default roles ship with Aptly and can be cloned to create Custom roles. Defaults themselves cannot be edited.
RoleDescription
System AdminUnrestricted view, edit, archive, and delete across all modules and records; full control of users, permissions, system settings, and logs.
Global Authority ManagerTenant-wide management of decisions, root delegations, approvals, matrices, actions, and documents; access to reporting/logs/version history; excludes system configuration.
Group Authority ManagerSame as Global Authority Manager but limited to assigned Groups; excludes tenant configuration; includes reporting/logs/version history.
Global UserView all decisions/delegations, matrices, actions, and documents; may request authority and delegate only authority granted to them; edit/version history limited to records where they are directly involved.
Group UserOperational access like Global User but restricted to assigned Groups; request authority and delegate only what has been granted to them; limited edit/history on directly involved records.
Restricted UserMinimal, targeted access to records explicitly shared with them or where they are an owner/issuer/recipient; no change-log/version history; may only edit where directly involved.
AuditorRead-only across the tenant, including logs and version history; no modifications allowed.
To tailor access, clone a default role (or create from scratch) and then adjust permissions, scopes, name, and description.

​
Permissions & scopes

Permissions are granular and scoped to Tenant (All) or Group. Common examples (not exhaustive):

​
Decisions

  • create_decisions, edit_decisions, archive_decisions, delete_decisions
  • issue_root_delegations (root), issue_delegation_decisions
  • view_history_decisions, view_log_decisions
  • Scope: Tenant or Group (e.g., view_group_decisions)

​
Delegations

  • view_delegations, edit_delegations, approve_delegations, archive_delegations, delete_delegations
  • issue_delegation_delegations (child), request_delegations
  • manage_roles_delegations, change_issuer_delegations, limit_override_delegations
  • Scope: Tenant or Group (e.g., approve_group_delegations)

​
Matrices

  • create_matrices, edit_matrices, share_matrices, archive_matrices, delete_matrices
  • Owner/user/group-shared variants (e.g., view_user_shared_matrices)

​
Documents

  • create_documents, edit_documents, share_documents, archive_documents, delete_documents, download
  • Role-based capacities on a document: Responsible, Reviewer, Approver (e.g., approve_reject, review)
  • Owner/user/group-shared variants and log/history viewers

​
Actions & Reports

  • create_actions, edit_actions, delete_actions (owner/assignee variants)
  • create_reports, edit_reports, archive_reports, delete_reports

​
Settings

  • manage_account_settings, manage_users, manage_roles, manage_groups, manage_notifications, manage_subscription, view_access_logs, manage_api_keys, manage_user_api_keys

​
Record capacities (FGA)

Many endpoints and UI actions check who you are to the record in addition to role permissions:
  • Owner (e.g., decision/matrix/document/report owner)
  • Issuer or Recipient (delegations)
  • Role Designee (delegations)
  • Responsible / Reviewer / Approver (documents)
  • Shared user/group (matrices, documents)
These capacities unlock actions such as approve/reject, reassign, change owner/issuer, view version history or view change log, as expressed in the authorization policies.

​
Custom roles

Create a role from scratch—or clone a default—and then:
  1. Select module permissions and actions
  2. Set the scope (Tenant “All” or specific Groups)
  3. (Optionally) constrain outcomes with directory/HRIS group assignments and workflows
Example: “Regional Legal Manager” with approve_delegations + view_decisions, scoped to Legal and EMEA Entities groups.

​
Tips for admins

  • Start broad, constrain with groups: Give the minimal tenant-level permissions required; use Group scopes and FGA capacities to narrow real-world access.
  • Use cloning for consistency: Clone a default role, rename, then adjust only what’s needed.
  • Audit visibility vs. change rights: Auditors see everything (incl. logs/history) without edit rights; Restricted Users see only what’s shared/involved.
  • Test with a pilot user: Validate effective access by assigning the intended mix of role + groups + capacity, then review available actions in UI/API.
Need help modeling roles and FGA to match your org structure?
Email [email protected] and we’ll walk through a recommended design.