Permission Model

DecisionOps uses four baseline roles: reader, contributor, approver, and admin. Those roles determine what a person can see, create, approve, or manage across the workspace.

Readers can browse decisions, monitoring, and other read-only views. Contributors can also draft and edit decisions. Approvers can do everything contributors can do and can additionally approve or supersede decisions. Admins manage organization settings, including members, API keys, integrations, rules, constraints, and repository policy.

Practical Boundaries

If a user can open a page but cannot change anything on it, that usually means their role includes read access but not the corresponding write scope. This is common on organization settings screens, rules, API keys, and integrations. Decision actions follow a similar pattern: contributors can write drafts, but approve and supersede actions require approver or admin access.

Where This Matters Most

Role boundaries are most visible on these pages:

• /decisions/new and /decisions/:decisionId/edit for draft and edit access
• /organization/members for invitations and role changes
• /organization/api-keys for create and revoke actions
• /integrations/github and /integrations/agents for setup and connection management
• /rules and /pr-gatekeeper/overrides for governance controls

If a control is disabled or missing, check the user’s workspace role first before assuming the page is broken.