Roles and permissions

What decides whether you can see a screen, and the two things a role cannot get you around.

Access is by role. A role is a set of module and action permissions, held per company — each company has its own role set and its own administrator, and a role can only be assigned to a user inside its own company.

What a permission actually gates

• The navigation. A module you cannot reach has no tab; a screen you cannot reach has no tile and no search result.
• The API. Every endpoint checks, so the gate holds whatever route the request arrived by — the console, an import, a scheduled job or ASK.
• Reporting. Every cube is checked on every query, so a report is not a softer door into data the screens protect.

Two things a role does not get you around

• Segregation of duties. Where the platform requires two people — payroll calculation and payroll approval, for instance — holding both roles does not let one person do both on the same run.
• The audit trail. Sign-in and sign-out and role changes are always recorded and cannot be switched off, by anybody, including an administrator.

Signing in as somebody else

An administrator investigating a problem can assume another user’s identity to see what they see. It requires two approvals, it is read-only unless explicitly widened, every call made under it is recorded as having been made under an assumed identity, and the person whose identity it is can see that it happened.