zia-look-up-rule-targets

ZIA: Look Up Rule Targets

Why this skill exists

Every ZIA rule resource (Cloud Firewall, DNS, IPS, URL Filtering, SSL Inspection, Web DLP, File Type Control, Sandbox, Cloud App Control) scopes by the same set of "who/where/when/what-device" target fields:

• users, groups, departments — who the rule applies to
• locations, location_groups — where the user is connecting from
• url_categories — which URL category the request hits
• devices, device_groups — which managed device the user is on
• workload_groups — which workload (cloud-asset) the connection is to/from
• labels — admin-assigned tags for organisation/reporting
• time_windows — which time-of-day schedule the rule honours

Every one of those fields takes IDs (or, for url_categories, canonical UPPER_SNAKE strings), not display names. The admin will almost always name them by display name. This skill is the single source of truth for "given a name, find the ID."

Centralising it here means every rule skill (zia-create-firewall-filtering-rule, zia-create-cloud-app-control-rule, etc.) can chain to this one instead of repeating — and re-decaying — the same lookup table.

Hard rules (apply to every lookup)

These rules are non-negotiable and override anything a rule skill might say in passing:

1. Read-before-write. For every rule target the admin names, run one lookup with the appropriate zia_list_* tool before assembling the rule payload.
2. Empty list is authoritative. If the list call returns no match for an exact-name lookup, the named target does not exist. Stop the rule create. Tell the admin plainly. Do not retry with split keywords, broader filters, larger page_size, unfiltered listings, or "let me also try without the filter to double-check." One call, one answer.
3. Never invent IDs. If a lookup returns nothing, never substitute a similar-looking ID, never skip the field that the admin named, never silently drop it from the payload. The rule payload must reflect the admin's intent verbatim or the workflow stops.
4. Never narrate the lookup. Don't tell the admin "I'm searching for the user group Engineering…" — just resolve, build the payload, and report what was applied. If you have to retry quietly (e.g. one retry with a different known-good knob, see the name= vs search= notes), retry quietly and report only the final outcome.
5. Don't pre-list targets the admin didn't name. If the admin says "create a rule for users in Engineering," resolve only Engineering. Don't dump the full user-group list as context, don't enumerate departments, don't list time intervals "in case they want one."
6. One target kind per call. Don't try to bundle a user lookup and a location lookup into one tool call.