Skip to content

Role Assignment

Applies to: All subscriptions

Purpose

Map the customer's actual job functions onto the seven available roles, settle the segregation-of-duties decision explicitly, and prove the result by testing rather than by inspecting a table.

Audience

The system administrator, with the customer's finance control owner — who owns the segregation decision, not the implementation team.

Prerequisites

  • User Creation gate passed
  • A list of users with their real job functions, not their job titles
  • The control owner available to make the segregation decision

Steps

1. Map from what people do, not what they are called

Job titles do not map to roles. "Finance Manager" is a checker in one organisation and a preparer in another. Ask what each person does:

What they do Role
Manage users and configuration; do not commit transactions Org Admin
Approve and commit tax documents Tax Controller
Prepare and correct documents for someone else to commit Tax Executive
Manage dispatch and vehicles Transport Manager
Update vehicle details and generate bills Logistics Operator
Review only; change nothing External Auditor
Administer the platform across tenants Super Admin — grant sparingly

2. Settle the segregation decision explicitly

SOD_ENFORCED defaults to on: preparation and commitment sit with different people.

Turning it off collapses maker permissions into checker permissions — and not only for the maker. Logistics roles and the organisation administrator also gain full transactional authority. It is a broad change, not a narrow one.

Legitimate Not legitimate
One person genuinely performs both functions, because there is no second person Getting past an approval step during testing
A small entity where separation is impossible A default applied because nobody decided
A temporary go-live measure that is never reviewed

Record the decision: who decided, when, the business reason, any compensating controls, and a review date. An auditor will ask, and "it was easier" is not an answer.

The setting is per registration, so a group can enforce it for the main entity and relax it for a small subsidiary. That option is under-used.

3. Understand what cannot be configured

Constraint Consequence
Roles are fixed No custom role builder
No per-user overrides A user needing one extra permission must move to the role that holds it, accepting everything else
Three levers only Role, registration access, segregation enforcement

Say this early. Customers frequently arrive expecting to define their own roles, and discovering the constraint at stage 4 is late.

4. Assign and confirm

Assign each user their role. Changes take effect at the user's next sign-in.

Where a person's function genuinely does not fit a role, document the gap rather than granting a broader role quietly. A recorded gap is a product conversation; a quiet over-grant is an audit finding.

5. Verify by testing

This is the step that matters, and the one most often replaced by reading the permissions table.

Test Expected
Sign in as a maker; attempt to register a document Refused, when segregation is enforced
Sign in as an org admin; attempt to register a document Refused
Sign in as an auditor; attempt any change Refused
Sign in as a logistics user; attempt to register a document Refused
Sign in as a checker; perform the full workflow Succeeds
Sign in as each real user; perform their real task Succeeds

The final row is the acceptance test. Everything above it is a control check.

Validation

Gate: this stage is complete when all of these pass.

Check Pass condition
Every user has a deliberate role Mapped from function, agreed with the process owner
The segregation decision is made and recorded By the control owner, in writing
Controls verified by testing Each control test above performed, not read
Each user can do their job Verified by them, on a real task
No over-granting Nobody holds a broader role to work around a gap
Gaps documented Where a function does not fit, it is recorded
Super admins minimal As few as possible

Rollback

Situation Action
Wrong role assigned Change it; effective at next sign-in
Segregation relaxed in error Re-enable immediately, and check what was done in the interim
Access granted too broadly Reduce it
A workflow stalls after a role change Check what the new role lost, not only what it gained

Role changes are fully reversible. What is not reversible is what was done while the wrong role was held — which is why the segregation setting deserves care.

Common mistakes

Mistake Consequence Avoid by
Mapping from job titles Roles that do not match what people do Ask what they do
Relaxing segregation for testing convenience A control silently disabled in production It is the control owner's decision, always
Granting a broader role for one missing permission Unintended authority Document the gap instead
Too many super admins Cross-tenant reach granted casually Grant sparingly
Verifying by reading the table Assumptions instead of evidence Test each control
Not recording the segregation decision An unanswerable audit question Record it at the time
Discovering "no custom roles" late Rework, or an unhappy customer Say it at kickoff

Troubleshooting

Symptom Cause Action
"Why can my colleague do this and I cannot" Maker versus checker By design. Explain the model
A user needs one extra permission No per-user overrides Move roles, or document the gap
A maker can suddenly commit Segregation relaxed Confirm it was decided; if not, re-enable
A logistics user can register documents Relaxation collapsed their permissions too The strongest argument for re-enabling
An org admin cannot register a document By design Configuration authority excludes transactional authority
A workflow has nobody able to commit A role change removed the only checker Check both directions of a role change