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.
Every screen can be put on a role
A role that is not set to all actions sees only the screens it is granted. Every screen in the console can be granted, including the boards, workbenches and reports that have no records of their own — the OEE board, the MRP workbench, the sourcing pipeline, every analytics report. On those, display is the only permission that means anything, so the other three are not offered. The screens only an administrator may open (users, roles, runtime settings and the like) are not in the grid, because a grant there would do nothing.
Each module has a Dashboard screen too — its figures, alerts and recent activity on the module’s home. Tick Display on it for a restricted role that should see them; a role set to all actions in its modules sees them already.
The lines on a document are part of the document. Granting Responses under Supply Chain → Strategic Sourcing gives the lines of a response with it: there is no separate "Responses Lines" permission to look for, and change on the header is what allows a line to be added or edited.
A role that holds a module but seems to show only its Dashboard is almost always one of two things: the role is restricted to named screens and none has been ticked yet, or the person has not been given the role at all — check Platform → Access → Users. A role granted to somebody who is signed in takes effect on their next screen, without signing out.
What each permission lets a person do
Every button that changes something answers to the permission on its screen. Creating a record is add. Anything done to a record that exists — approve, post, receive, release, submit, cancel, reverse, edit its lines — is change. Removing one is delete. Reading, running a report or a preview is display. A role granted only display on Purchase Orders can see an order and cannot approve, receive or add a line to it; a role with change can.
The role editor spells this out on each screen’s row: "Change also: receive, submit for approval, edit lines". Every permission a button asks for has a box to tick. Approvals routed to a named person or a role are decided only by that person or role, and an approval rule cannot be saved if it routes to a role that could not open the approval.
The same holds outside the modules: attaching or removing a document, custom-field values, classifications, a connected drive, a spreadsheet import, and cancelling or reversing an invoice or order all ask for the permission on the screen the record belongs to.
Finding one user among hundreds
Platform → Access → Users has the same search and conditions as every other list: type part of a name, an email or a role, or add a condition (Status is disabled, Roles contains Finance). A new user whose email is already taken is refused inside the New user form, where you are typing, rather than on the list behind it.
Finding a role
- Platform → Access → Roles has a search and filter bar like any list: type part of a role’s name, code or description, or the name of a module it reaches.
- In the Users drawer, where roles are ticked for a person, Find a role narrows the list when a company has many roles.
- The pickers that choose a role for a signing limit can be searched the same way.
People who signed in before they were given a role
Where single sign-on is set to create a sign-in for new people, somebody your company directory signs in with no TRANXACT account is given one that reaches Help & Support only. Users lists them marked "Created at first sign-in". Open the user, give them their real role, and it applies on their next screen. See Signing in for the first time through your company directory.
Reports reach no further than the modules
A report that draws on several modules at once answers only for somebody whose roles really reach those modules. A role that opens Help & Support alone, or only a module’s dashboard, sees none of them.
Signs in as, on an employee record, links a sign-in to that employee. It accepts only users of the same company, or users given access to that company.
A new screen is granted like any other
Fixed Asset Details, Fixed Asset Labels and Document Retrieval, under Supply Chain, are granted separately: counting assets needs add on Fixed Asset Details, printing labels add on Fixed Asset Labels, and looking up a material document display on Document Retrieval. The warehouse roles and the Asset Accountant are given what their work needs.
CRM → Lead Contacts, the people at each lead, is granted on its own like any other screen: add to create or import contacts, change to edit them, display to see them, delete to remove them. A role that manages leads normally needs both Leads and Lead Contacts.
Every screen a release adds can be granted per role under Platform → Roles, with the same four permissions as the rest: add, change, display and delete. Certificates, Retention Policies, Retention Runs and Archived Records are the latest. Nobody reaches them until a role says so, apart from the administrator.
Migration Cockpit and Migration Readiness can be granted per role too. On the cockpit, add is uploading an extract, delete is discarding one or resetting the cutover, and every other action is change. The Migration Lead and Go-live Reviewer roles are ready to assign. See Coming across from another system → Who may do what.
On some screens a permission means more than its name suggests, because the action behind it is the one that cannot be undone. On Retention Policies, running a purge or switching a purge policy on needs delete, not change — a purge deletes records, and the permission that deletes records one at a time should be the one that deletes them by the thousand. See Keeping and removing old data.
The actions added at the end of September are granted like the rest, on the screen they belong to:
| Action | Where it is | Permission it needs |
|---|---|---|
| Register serials | A line of a goods receipt | Add or change on Goods Receipts, or add on Serial Numbers |
| Plan separation, Change status, Cancel scheduled change | HRMS → People → Employees | Change on Employees |
| Apply to a posting, Add application | An HRMS candidate, a job posting | Add on Applications |
| Submit to a job order, Add a candidate | Talent & Contingent Workforce | Add on Submissions |
Handing your "Needs your attention" list to a colleague while you are away, or forwarding one item, needs no grant. It is personal: it moves what shows on a dashboard, not what anybody may open.
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.
Since 20 October new shipped roles include Security administrator, Security & AI Governance Admin, Records & Legal Admin, Governance Auditor (read only), Benefits Administrator, GL Interface Administrator, Payroll Auditor (read only), Learning & Development Administrator, HR Auditor, HR Recruiter and EEO Officer. HR Auditor reads the HR screens — people, recruiting, time and leave, learning, skills, performance, benefits, expenses and records — but not payroll; Payroll Auditor reads payroll (runs, payslips, pay rates, tax, garnishments, the GL interface and parallel payroll). A company that wants both gives a person both roles. See HRIS/HCM capability map.