How is requestability decided?
What an employee may request is set on their entitlement, not here. Settings → Policies → Request policies opens Entitlements instead, where the Can be requested switch decides it per plan, and a category's conditions decide it for hardware.
See How do I decide which software a group gets? and What can I set on an entitlement category?.
The rest of this article describes how request policies work as a model. It is background rather than instructions.
In this guide
Before you begin
You need Admin access. You also need a rule-set of the matching kind, because a policy cannot be saved without one. See How do I use rule-sets for approvals?.
Software or hardware — decide first
A policy scopes either the software catalogue or the hardware store. Never both.
This choice is locked after creation: "The catalog kind can't be changed after the policy is created." Picking wrong means deleting the policy and starting again, so decide before you build the rest.
Who it applies to
Four targeting modes:
| Mode | Matches |
|---|---|
| Company-wide | Every employee |
| Groups | Employees in any of the groups you pick |
| Attribute match | Employees meeting all the conditions you set |
| Raw JSON Logic | Advanced, for targeting the builder cannot express |
Groups is the usual answer, and it is why virtual groups are worth setting up — the group keeps itself current and the policy follows.
What can be requested
For a software policy: either All services in the catalogue, or only the services you pick. An empty pick list grants nothing, and the editor says so — "Pick at least one service".
For a hardware policy: allowed store categories, either all or specific, plus three refinements:
- Blocked categories — hidden even when otherwise allowed
- Excluded products — never requestable under this policy
- Always include products — requestable even outside the allowed categories
Use Always include for the one exception you do not want to restructure your categories around.
How it is approved
The rule-set carries the approval flow, the duration and whether a justification is required. Attach one.
Priority is the field people misread. It does not decide which policy is stronger. When several policies match an employee, the stricter approval wins — with one exception for hardware: approval is decided per item, and a policy that names the item's category beats one covering all hardware, however strict. Priority only breaks ties between policies that are equally specific and equally strict, where the higher number takes precedence. See Who approves a request?.
Publish it
A policy moves through Draft → Live, and can later be Paused or Archived. Draft policies affect nothing. Use the Preview tab before going live.
Create with assistant
Create with assistant lets you describe the policy in words and have the assistant propose it. You get Apply or Dismiss on the proposal — nothing changes until you apply it. It is a drafting shortcut, not an authority: read what it proposes against the sections above.
Good to know
Why does my policy say it is superseded?
Another live policy already covers the same people and products with approval at least as strict, so this one can never change an outcome. See Why is my request policy superseded?.
Can one employee be covered by several policies?
Yes, and it is normal. Access adds up — they can request anything any matching policy allows. Approval does not add up: the strictest matching rule-set governs, except that for hardware a policy naming the item's category comes first.
What if nobody matches?
Nothing happens, silently. The Preview tab is how you find out before your employees do.
Does a policy grant access, or only permission to ask?
Permission to ask. What happens after a request is approved depends on the service's provisioning setup. See What is provisioning and deprovisioning?.
Was this article helpful?