Admin Guides / Approval policies
Approvers
Each place an approval rule can find its approvers, what happens when it finds nobody, and how to name collection and entitlement approvers.
Each rule in an approval policy has an approver source: where it looks for the people to ask. Only active people count, and a group counts only if it is active and has at least one active member.
| Source | Who is asked |
|---|---|
| Line manager | The manager of the person the access is for, not the person who submitted the request |
| Entitlement owner | The owner on the requested entitlement |
| Collection approvers | The access approvers named on the entitlement's collection |
| Entitlement approvers | The access approvers named on that one entitlement. Nothing is inherited from the collection. |
| CMDB CI field | A user or group read from the collection's configuration item, up to three fields away, such as managed_by or location.company.support_group |
| Named user | One person |
| Group | One group. Any one member or all members approve, as the rule says. |
When a source finds nobody
The rule's When the rule finds nobody setting applies, and the reason is recorded:
| Source | Reasons recorded |
|---|---|
| Line manager | The person has no manager recorded, or their manager is inactive |
| Entitlement owner | The entitlement has no owner, or its owner is inactive |
| Collection or entitlement approvers | None are defined, none are active, or none match the role filter |
With Use a standby approver, the rule's own person, then its own group, is asked. If neither can act, the approval exception group is asked, and if there is none the request stops.
Collection and entitlement approvers
Collection approvers and entitlement approvers are lists you keep in Warde, separate from owners, for applications where the people who approve are not the people who own. Each row names a person or a group, for either a collection or one entitlement, and can be tagged with a role:
| Field | What to enter |
|---|---|
| Collection | The collection this approver covers. Set this or Entitlement, not both. |
| Entitlement | The one entitlement this approver covers. Set this or Collection, not both. |
| Approver user | The person who approves. Set this or Approver group, not both. |
| Approver group | The group that approves. Set this or Approver user, not both. |
| Role | Optional: Business, Technical or Security. Untagged approvers count for every rule. |
A rule with a role filter asks the approvers tagged with that role plus the untagged ones. A rule with no filter asks all of them.
Where to edit them. Collection approvers are on the collection form's Access Approvers list, and on the Decide how requests are approved step of Collection Onboarding, where you choose a person or a group, an optional tag, and add them. Entitlement approvers are on the entitlement form's Access Approvers list. Every row, for every collection and entitlement, is in the Admin Workspace under Policies, then Access approvers. A row added from a form's list has its collection or entitlement filled in.
Collection Onboarding flags the approvals step, and warns before go live, when the collection's approval policy has a Collection approvers rule that applies to every request and nobody listed can approve for it.
The Approval policy health tab of the Access health dashboard counts collections with no access approvers, and inactive collection and entitlement approvers.
Choosing a source
| If | Use |
|---|---|
| Managers know what their people need | Line manager |
| One person is accountable for each piece of access | Entitlement owner |
| A team decides for a whole application, perhaps by role | Collection approvers, with a role filter per stage |
| One sensitive entitlement needs its own approvers | Entitlement approvers |
| Your CMDB already records who manages each application | CMDB CI field |
| A fixed group approves everything of a kind, such as privileged access | Group, usually with a condition |