Skip to content
ZHERO Docs

Policy Reordering

Order is policy. A rule ten places too low does nothing, and a rule three places too high can silently disable everything below it. The Zscaler console lets you move rules one at a time; ZHERO lets you arrange the whole list and commit the result.

It is for anyone fixing a shadowing problem, prioritising a new rule, or reorganising a policy set after an audit.

When to use it

  • After an audit finds specific allow-rules sitting below a broad block.
  • When unreachable policy detection flags a cluster of rules shadowed by the same catch-all.
  • Prioritising a new rule above the general-access ones, during a migration or a rollout.
  • Any time you would otherwise move five rules by hand and hope you counted right.

Where to find it in the UI

Open Dashboards → Entities, choose a policy entity type, and click Reorder in the toolbar. The table gains drag handles and a position column, and the toolbar changes to Commit Order and Cancel.

Reordering works on both ZIA and ZPA policy types.

Step by step

  1. Enter reorder mode. The position column shows two values per row: the original position, read-only and visually distinct, and the current position, editable.
  2. Move the rules, three ways:
    • drag a row to its new place
    • type the target position in the row’s input, for precision in a long list
    • select several rows and move them together to a target position, preserving their relative order
  3. Check the list before committing. Everything so far is local: nothing has been staged and nothing has been sent to the tenant.
  4. Commit Order. ZHERO computes the minimum set of move operations that turns the original order into the one you built, and stages them as individual items in Pending Changes, sequenced so that executing them in order produces exactly the arrangement you designed.
  5. Review and execute in the pending drawer, like any other change.

Cancel leaves reorder mode and restores the original order. Committing with nothing actually moved creates no pending changes, and says so.

What to watch

  • Locked rows. Default rules with a fixed position (for example the default firewall filtering rule) appear greyed and locked. They cannot be dragged, edited or included in a bulk move. That is Zscaler’s constraint, not a ZHERO limitation.
  • The move count. Committing a big rearrangement usually stages fewer items than rows you moved, because the minimum-move calculation removes the redundant ones. If the number looks surprisingly small, it is working.
  • Sequence matters. The staged moves depend on each other: each one shifts the positions of the rules around it. Execute them in the order they were staged, which is what the queue does by default.
  • Reordering does not change the rules, only where they sit. Nothing about a rule’s criteria or action is touched.

Limits and notes

  • The snapshot is optimistic. Reordering works against the list as loaded. If someone changes the policy in the console while your changes sit in the queue, the conflict guard catches it at execution, and the pending drawer carries a standing reminder that queued changes reflect a point-in-time snapshot.
  • A rule deleted in the console while your moves are queued makes its move fail at execution with an error on that item. The rest of the queue is unaffected.
  • ZIA and ZPA reorder differently under the hood. ZIA carries position as a field on the rule, ZPA has a dedicated reorder operation. ZHERO handles both; you see the same interface.
  • Duplicate order numbers in the source data are shown in the order the API returned them, and the list position is treated as canonical.
  • Reordering follows the same permissions as creating any pending change.

FAQ

Can I reorder without staging, straight into the tenant? No. Every change goes through the pending queue, which is where the diff and the conflict guard live.

Why can I not move the default rule? It is a system rule pinned to its position by Zscaler. ZHERO shows it locked rather than letting you attempt a move that would fail.

I moved eight rules and only three pending changes appeared. That is the minimum-move calculation: three moves are enough to produce the order you built. The result is the same, with less to execute and less to go wrong.

Does bulk move keep my selection in order? Yes. A selected group moves as a block and keeps its internal order.

Can I reorder ZPA access policies and client forwarding policies? Yes, both, along with the ZIA policy types.

Next steps

  1. Find a shadowed rule through the Analysis Engine
  2. Open the Entities tab on that policy type and enter reorder mode
  3. Select the shadowed rules and bulk-move them above the rule that catches their traffic
  4. Commit, review the staged moves, execute, and re-run the analysis