Administrator guide
Roles and access
The five roles Warde ships, who should hold each one, and how Warde keeps identity administration separate from platform administration.
Warde ships five roles, all in its own scope. You grant them in Guided Setup step 1, or from the user, group or role record like any other role.
The roles
| Role | Name on the instance | What it lets someone do |
|---|---|---|
| Administrator | x_66256_warde.idam_admin | Set up and run Warde: engines, collections, entitlements, access bundles, approval policies and the fulfilment queue. The only role that opens the Admin Workspace, Collection Onboarding and the Approval Policy Wizard. |
| Requester | x_66256_warde.requestor | Ask for and remove access, see their own accounts and access on My Access, open access reviews assigned to them, and approve or reject the entitlements they own when an access bundle is proposed. Managers also see their team's access. |
| Fulfiller | x_66256_warde.fulfiller | Read the Warde records behind a request: fulfilment operations, request lines, accounts and engines. The manual work itself is an ordinary catalog task, so this role only explains why a task exists. |
| Lifecycle integration | x_66256_warde.lifecycle_integration | Call the joiner, mover and leaver endpoint and ask what became of a call. Nothing else. |
| Reviewer | x_66256_warde.reviewer | Nothing. It marks the people responsible for access reviews, for customers who want that recorded on the user. |
Every request still goes through approval and fulfilment, whatever role the person asking holds. The requester role gives read access to a person's own records only.
Who should hold each role
Administrator. The small team that runs identity and access. If fewer people should run Warde than run the instance, grant it to a named group rather than putting it under admin. The administrator role includes canvas_user, so the Admin Workspace opens without a second grant. Only a platform administrator can grant it.
Requester. Everyone who may ask for access or review it. Most instances put it under snc_internal, which every internal user has. If only part of the business should ask for access, grant it to named groups instead, and put your reviewers and entitlement owners in one of those groups: reviewers and owners need the requester role too. Nobody holds it when Warde is installed, so the request forms are empty for everyone until you grant it.
Fulfiller. Put it under itil so the service desk and fulfilment staff who already work tasks can see the Warde records behind them.
Lifecycle integration. The service account your HR system or identity platform signs in with to call Warde. Do not also give that account the administrator role: an account that can grant access should not be able to change the rules for it.
Reviewer. Optional. A review task is worked by the person it is assigned to, or by someone they have delegated tasks to, whether or not either holds this role.
Separating identity administration from platform administration
Warde turns on application administration. Once that is in force, holding the platform admin role does not let someone see or change identity data: they need an explicit grant of the Warde administrator role.
When Warde is installed, the platform admin role contains the Warde administrator role, so every platform administrator can start setup. This is the same pattern ServiceNow's own scoped applications use. Guided Setup step 1 shows it as an open item. Once you have named your own administrators, open the record from that step and delete it.
After the removal, a platform administrator who needs Warde has to be granted the administrator role, which leaves a sys_user_has_role record with who granted it and when.
What each page needs
| Page | Roles |
|---|---|
| Guided Setup | admin or the Warde administrator role |
| Admin Workspace, Collection Onboarding, Approval Policy Wizard, Contact Support | Warde administrator role |
| My Access, the request and removal forms, reviews | Requester role |
| The joiner, mover and leaver REST endpoint | Lifecycle integration role |
| Platform configuration in the Warde menu: transform maps, import sets, roles and ACLs, application code, tests and logs | admin |
Audit evidence
Warde's audit history and the record of terms people accepted are append-only. No role, including admin, can edit or delete them through the interface. Administrators can read the audit history, and the requester and the person the access was for can each read the terms they accepted. Retention is set in Guided Setup step 11.