--- sourceDocument: Australia Enable AI sourceDocumentLink: https://www.servicenow.com/docs/r/australia/intelligent-experiences Release : - australia ft:locale : - en-US ft:publication_title : - Australia Enable AI ft:clusterId : - platai bundleId : - platai workflow : - Platform --- # Policy stacking and precedence # Policy stacking and precedence in ServiceNow Arc {#ariaid-title1} Release version: Australia Updated October 23, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Policy stacking and precedence in ServiceNow Arc ServiceNow Arc allows multiple active policies to apply to a single user by merging them into one effective policy. This merging process considers priority, specificity, and restrictiveness to resolve any conflicts between rules from different policies. This ensures tailored and precise access control without altering default policies directly. Show full answer Show less ## How Policies Merge Each policy applies based on user criteria, and Arc combines all matching policies into a unified set of rules delivered to the user's Arc application at the next sync. Non-conflicting rules from different policies accumulate, such as network rules adding to an allowlist rather than replacing it. ## Conflict Resolution * **Tool gates, sandbox rules, and capability overrides:** The rule from the policy with the lowest priority number prevails. The default Arc policy has priority 999; new policies start at 100, so they override the default unless assigned a priority above 999. For capability overrides from policies with equal priority, the more restrictive option applies. * **Approval patterns:** Patterns across policies are compared; the one matching more of the command takes precedence. If patterns match equally, the pattern's priority, then the policy's priority, and finally the gate restrictiveness determine precedence. * **File type rules:** The rule from the policy with the lowest priority number wins when multiple policies cover the same file extension. ## Restrictiveness Hierarchy Arc ranks rules by restrictiveness within each rule type to determine precedence where applicable: * **Tool gate:** Block \> Require approval/auto approval \> Allow * **Approval pattern:** Hard gate \> Soft gate \> Allow carve-out * **File type rule:** Deny all access \> Allow read/write \> Allow read only * **Network rule:** Not on allowlist \> On allowlist * **Sandbox filesystem rule:** Deny \> Read and write \> Read only * **Connector scope:** Scope off \> Scope on ## Changing Default Behavior via Policy Layering Instead of modifying the default Arc policy, create a new policy layered over it to override specific rules. This approach maintains default policy integrity and updates, makes policy changes transparent, and allows easy reversal by deactivating or deleting the overlay policy. To layer a policy: * Create a policy targeted to specific users or groups using user criteria. * Assign a priority below 999, typically starting at 100, to override the default. * Include only the rules requiring changes; other rules inherit from the default policy. ## Practical Example If developers need access to an internal package registry (e.g., registry.example.com) blocked by the default policy, create a developer-group policy with an active network rule allowing the registry. On the next sync, developers receive a merged allowlist combining the default and new rule, enabling access for that group only. When more than one policy applies to a user, Arc merges them into one effective policy and resolves any conflicts by priority, specificity, and restrictiveness. ## How policies merge {#gov-pol-policy-stacking-precedence__how-policies-merge} More than one active policy can apply to the same user, for example the default Arc policy and a policy for a support team. Each policy's user criteria decide which users it applies to. Arc merges every policy whose user criteria match the user into one effective policy, and the user's Arc application receives that policy at its next sync. Rules from different policies add up. For example, a network rule in your policy that allows a new host joins the default allowlist instead of replacing it. Two rules conflict only when they govern the same thing, such as two tool gates for the same tool or two file type rules for the same extension. ## How conflicts are resolved {#gov-pol-policy-stacking-precedence__how-conflicts-resolve} When two rules conflict, how Arc picks the winner depends on the rule type. Tool gates, sandbox rules, and capability overrides : The rule from the policy with the lowest priority number wins. The default Arc policy has priority 999, and new policies start at 100, so a new policy overrides the default policy unless you set its number above 999. If two capability overrides come from policies with the same priority, the more restrictive value applies. Approval patterns : Patterns from every policy that applies to the user are compared together. The pattern that matches more of the command wins first, whatever policy it comes from. For example, when a user runs `git push --force`, a pattern for `git push --force` takes precedence over a pattern for `git push`. Among patterns that match equally well, the pattern's own priority decides, then the policy's priority, then the more restrictive gate. File type rules : When rules from different policies cover the same extension, the rule from the policy with the lowest priority number wins. ## Restrictiveness by rule type {#gov-pol-policy-stacking-precedence__restrictiveness} {#gov-pol-policy-stacking-precedence__table-restrictiveness__entry__2} | Rule type | Most restrictive to least restrictive | |-|-| | Tool gate | Block, then require approval or auto approval, then allow | | Approval pattern | Hard gate, then soft gate, then allow carve-out | | File type rule | Deny all access, then allow read and write, then allow read only | | Network rule | Not on the allowlist, then on the allowlist | | Sandbox filesystem rule | Deny, then read and write, then read only | | Connector scope | Scope off, then scope on | [Table 1. Settings from most to least restrictive] {#gov-pol-policy-stacking-precedence__table-restrictiveness} ## Changing default behavior {#gov-pol-policy-stacking-precedence__change-defaults} To change how Arc behaves by default, create a policy that layers over the default Arc policy instead of changing the default itself. Layering has the following advantages: Intact defaults : The default Arc policy stays unchanged and keeps receiving product updates. Explainable policy : The override and the rule it overrides both exist as records, so you can explain the effective policy. Reversible changes : To undo the change, deactivate or delete your policy, and the previous behavior returns. To layer a policy over the default: 1. Create a policy and set its user criteria to the users or groups it applies to. 2. Keep its priority number below 999. New policies start at 100, so the default value works unless you're layering over another policy of your own. 3. Add only the rules you want to change. Anything you don't add keeps coming from the default Arc policy. {#gov-pol-policy-stacking-precedence__ol-change-defaults} For the steps, see [Create an Arc policy](https://www.servicenow.com/docs/nRQyQecN9oZaWQj43IiBEA "Give a team its own ServiceNow Arc rules by creating a policy that applies to the users you choose and takes precedence over the default Arc policy."). ## Example: Allow a site that the default Arc policy blocks {#gov-pol-policy-stacking-precedence__example-network-rule} Your developers need Arc to reach your internal package registry at registry.example.com, which isn't on the default allowlist. To allow it, create a policy for the developer group and add an active network rule that allows registry.example.com. At the next sync, the developers' Arc application receives the default allowlist and your rule merged together, so the registry is reachable for developers only.