Skip to content
ZHERO Docs

ZPA Domain Management

Application segments are lists of domains, and lists of domains are exactly what nobody wants to maintain one row at a time. This is the bulk editor: paste a list, move a set between segments, clone a segment from an existing one, with conflict checking before anything is staged.

It is for whoever owns the ZPA estate after a reorganisation, an acquisition, or a SaaS rollout.

When to use it

  • Onboarding many domains at once, instead of adding them one by one.
  • Consolidating after an acquisition, when domains are scattered across segments that no longer reflect the organisation.
  • Splitting a segment that has grown too broad, by cloning it and moving a subset out.
  • Cleaning up domains that no longer resolve to anything you host.

Where to find it in the UI

Open a ZPA Application Segment entity and use its domain management actions. Every operation stages into Pending Changes rather than writing to the tenant.

What you can do

OperationWhat happens
Bulk editEdit the domain list as text, one per line. ZHERO deduplicates, computes the difference against the current list, and stages only what actually changed
Bulk deleteRemove the selected domains from the segment
Move to another segmentTwo linked changes: removed from the source, added to the target
Copy to another segmentOne change: added to the target, source untouched
Move or copy to a new segmentClone the source segment’s settings into a new one, with a name you choose, editable TCP and UDP port ranges, and a segment group that defaults to the source’s

The target segment is chosen from a searchable picker grouped by segment group, showing each segment’s enabled state, domain count and port summary. The source segment cannot be chosen as its own target.

The port conflict check

The same FQDN can legitimately live in two segments, or it can be a mistake that makes access non-deterministic. ZHERO checks before staging, on every operation that can put a domain in more than one segment: bulk-edit additions, move and copy.

SituationTreated as
Same FQDN, exactly overlapping port ranges, in segments without multi-matchConflict
Same FQDN, one range strictly inside the other (for example 443-443 within 1-65535)Not a conflict
Same FQDN, ranges that overlap without containment (for example 400-500 against 450-600)Conflict
Both segments have multi-match enabled, and the tenant supports itNot a conflict

When a conflict is found, the dialog names the other segment, the overlapping ranges and the multi-match state of each, and you decide: override, cancel, or proceed with only the non-conflicting domains. On a move, the source segment is excluded from the check, since the domain is leaving it.

Step by step

  1. Open the application segment and its domain list.
  2. Choose the operation: edit the list as text, or select domains and move, copy or clone.
  3. Pick the target where the operation needs one, from the grouped picker.
  4. Read the conflict report if one appears. Partial is a valid answer: stage the domains that do not conflict and deal with the rest separately.
  5. Review the diff in Pending Changes and execute.

What to watch

  • Only the difference is staged. Pasting a 400-line list back with two lines added stages two additions, not 400 changes. The diff is what you review.
  • Duplicates are collapsed before the difference is computed, so a pasted list with repeats does not produce repeated work.
  • A move is two changes, not one. They are linked, and the queue keeps them together.
  • Cloning copies settings, not history. The new segment starts with the source’s configuration and the name and ports you give it.
  • Multi-match visibility depends on the tenant. Where the tenant does not have the multi-match capability, the related interface and validation references are simply not shown.

Limits and notes

  • Nothing here writes directly. Every operation lands in the pending queue with a full diff.
  • The conflict check is about ports and FQDNs, not about whether the domain should be in that segment at all. That judgement stays with you, and Broad Scope Domain Detection is the analysis that questions it.
  • Overriding a conflict is a decision, recorded in the queue like any other change. If access to that FQDN becomes non-deterministic afterwards, this is where it started.
  • Port range formats differ between older and newer tenant data; ZHERO normalises them before comparing, so the conflict report is consistent.

FAQ

What happens if I paste a list that removes half the segment’s domains? The diff shows the removals explicitly, and they stage as changes you can review before executing. Pending changes exist precisely so a paste error is a reviewable diff, not an outage.

Can I move domains into a segment that does not exist yet? Yes. Move or copy to a new segment clones the source’s settings into a new one, with your name, port ranges and segment group.

Why is a domain flagged as a conflict when the ports are different? Because they overlap without one being contained in the other. Two segments claiming 400-500 and 450-600 on the same FQDN is ambiguous. Identical ranges also conflict; a strict subset does not.

Does this work on segments with wildcards? The bulk operations handle whatever the segment holds. Whether a wildcard belongs there is a separate question, and the broad-scope analysis template is the one that raises it.

Next steps

  1. Open a segment you know has grown messy and read its domain list as text
  2. Try a copy to another segment and read the conflict report before staging
  3. Use clone to split an overly broad segment in two
  4. Re-run the analysis afterwards and check the broad-scope finding has cleared