Domain overlaps

A given hostname showing up in two different segments is not automatically wrong - sometimes you intentionally split coverage by user group. But if the policies attached to those segments disagree on the action, you have a coverage rules race that ZPA decides via rule order, not via your intent.

Endpoint

GET /api/v1/analytics/domain-overlaps

Returns

type DomainOverlapDetail struct {
    Domain      string
    Segments    []DomainSegmentDetail
    HasConflict bool                  // true if at least two policies disagree on Action
}

type DomainSegmentDetail struct {
    ID       string
    Name     string
    Policies []NamedRef // policies attached to this segment
}

Sorted: conflicts first, then alphabetically by domain.

How

1. Walk Index.OverlappingDomains (built during index time as “domains that appear in more than one segment”).
2. For each entry, list the segments and the policies attached to each.
3. Collect every distinct pol.Action across all the policies. If the set has more than one value, HasConflict = true.

Wildcards count

*.example.com in segment A and db.example.com in segment B both cover db.example.com. The reachability code walks the wildcard hierarchy, but this report lists raw entries only - it shows the literal duplicates and skips implicit wildcard collisions.

If you want the wildcard-walk view, use the reachability query on a specific hostname.

Use it for

• Conflict triage. HasConflict = true means the policies disagree. Investigate which one is supposed to win; delete or rescope the other.
• Drift detection. Pure shadows (HasConflict = false) often mean two teams added the same domain to different segments without coordinating. Pick one canonical owner.
• Cleanup before SCIM-group rework. Resolving overlaps first makes shadow analysis easier to read.