Administrator guide
Approvals
Build approval policies in the Approval Policy Wizard, and decide which policy a request uses and what happens when nobody can approve.
Every request for access goes through an approval policy. A policy is a list of stages that run one after another. Each stage holds one or more rules that run at the same time, and each rule finds its approvers in records you already keep: a person's manager, the entitlement's owner, a group, a field on a configuration item.
Approvals are ordinary ServiceNow approval records, so approvers decide from the approval email, My Approvals or the approval record, the same as any other catalog approval.
Which policy a request uses
Warde looks for a policy in this order and uses the first it finds:
- The entitlement's approval policy
- The access bundle's approval policy, for access requested in a bundle
- The collection's approval policy
- The instance default, set in Guided Setup step 6
If none of them names a policy, the request stops and waits for an administrator. There is no hidden fallback approver.
Removals follow the same order with the removal approval policies, and the removal approver setting decides whether a removal needs approval at all.
Build a policy
Open Warde > Approval Policy Wizard, or select Build a policy in Guided Setup. A new policy is active as soon as you name it. The wizard has four steps.
1. Name the policy
Give it a name approvers and administrators will recognise, such as Manager then application owner.
2. Design the stages
Add stages in the order they should run, and rules inside each stage. For each rule:
| Setting | Choices |
|---|---|
| Approvers come from | Line manager of the person the access is for, Entitlement owner, Collection approvers, Entitlement approvers, a field on the collection's configuration item, a named person, or a group |
| Role filter | For collection and entitlement approvers only: ask only approvers tagged Business, Technical or Security |
| How many must approve | Any one of them, or all of them |
| Label | Line manager, Technical, Business or Elevated. It names the approval in records and messages and does not change who approves. |
| Condition | Run the rule only for request lines that match, such as entitlement risk is high or account type is admin. Empty runs it every time. |
| When the rule finds nobody | Ask a standby approver, skip the rule, or stop the request for an administrator to check |
A configuration item field can follow up to three fields, such as managed_by or location.company.support_group. Inactive people, and groups with no active members, do not count as approvers.
A standby approver is a named person or group the rule falls back to. If the rule has no usable standby, Warde asks the approval exception group from Guided Setup step 6. One answer from that group is enough, and it is never asked about a request one of its own members raised. If no exception group is set, the request stops.
A policy with no rules stops every request that reaches it. Guided Setup and the wizard both mark such a policy.
3. Test the policy
Choose a real entitlement and a real person. The wizard shows who would approve at each stage, found the same way as for a real request. Nothing is created. A condition on requested item fields cannot match in a preview, and a real request with several items can have more stages than the preview shows, because their stages are combined.
4. Where it applies
Lists everything that uses the policy: entitlements, collections, access bundles and the instance defaults. A change applies to every request submitted after you save it.
How a request is approved
- One decision for the whole request. A request with several items or several people is approved or rejected as a whole. One rejection rejects all of it.
- Stages combine. When items on one request use different policies, their stages are merged into one approval chain for the request.
- A stop holds everything. If any line cannot find an approver and its rule says stop, the whole request waits for an administrator.
- The person who submits. By default a submitter who is also an approver is asked like anyone else. Guided Setup step 6 can count their submission as their approval instead.
- Delegates. Platform delegates of an approver can approve, and the record shows who acted.
Approvers see what Warde knows about the request in a comment on the approval record headed Warde: before you approve: any important approval information, separation of duties findings, and access the request will replace. The approval's reason line says when there is such a comment. Add ${comments} to your approval notification so the email carries it too; the Guided Setup email card checks whether your notification does. The Employee Center approval page has no place for the comment, so approvers who only use the portal see the same notice in the approvals panel on My Access.
Who approves a removal
Set in Guided Setup step 7:
| Setting | Who approves |
|---|---|
| The person who has the access (default) | The holder. A person removing their own access is not asked again. |
| Their line manager | The holder's manager. If the manager is missing or inactive, the approval exception group. |
| The removal approval rules | The removal approval policy on the entitlement, then the collection, then the instance default removal policy |
| Nobody | No approval |
When the person removing the access would approve it themselves, or is a delegate of that approver, their request counts as the approval.
Bundle proposals
Proposals made with Onboard an Access Bundle are approved by the bundle approvers group, then each entitlement owner. See Access bundles.
Policy health
The Approval policy health tab of the Admin Workspace's Access health dashboard counts the gaps that make a request stop or skip: policies with no rules, rules with no approver or an inactive one, rules on a group with no active members, rules that skip or stop if nobody is found, inactive policies still in use, and high-risk entitlements with no policy of their own. Each count opens the list behind it.