zpa-application_segment-onboard
End-to-end onboarding of a new application in Zscaler Private Access. Walks through the complete dependency chain: (1) App connector group, (2) Server group, (3) Segment group, (4) Application segment with domain names and ports, (5) Access policy rule to grant user/group access. Use when an administrator needs to make an internal application accessible through ZPA.
What this skill does
# ZPA: Onboard Application
## Keywords
onboard application, new application, add application, zpa application, publish application, application segment, private access, zpa setup, application access, zero trust application
## Overview
Onboard a new application in Zscaler Private Access by walking through the full resource dependency chain. This skill creates all required ZPA constructs -- from connector groups to access policies -- ensuring the application is reachable and properly secured.
**Use this skill when:** An administrator wants to make a new internal application accessible through ZPA, or needs a guided walkthrough of the full ZPA application onboarding process.
---
## Workflow
Follow this 8-step process for complete application onboarding. Step 0 is new — it picks the segmentation pattern, which then drives the right defaults in every later step.
### Step 0: Classify the Application (baseline alignment)
Before creating anything, ask the administrator one question: **what kind of application is this?** The answer drives the defaults for AC group, server group, segment group, and `health_reporting` mode. Reference: ZPA Baseline Recommendations v1.0 §App Segmentation Recommendations.
| Class | Examples | App Connector Group | Server Group | Health Reporting |
|---|---|---|---|---|
| **Standard** (general business app) | Wiki, ticketing, internal SaaS | Communal, per location | Communal per location, `dynamic_discovery=True` | `ON_ACCESS` |
| **Sensitive / regulated** (Finance, HR, Legal, PCI) | Workday, SAP HCM, financial systems | **Dedicated isolated** secure-enclave AC group | **Dedicated** SG bound to enclave AC group only | `ON_ACCESS` (use `CONTINUOUS` only for multi-DC critical) |
| **Global** (one app, accessed from everywhere) | AD DCs, NTP, internally LB'd web | All location AC groups | **Global SG** spanning all AC groups | `ON_ACCESS` |
| **Discovery** (wildcard for unknown apps) | `*.corp.example.com` | All communal AC groups | **Global Discovery SG** | **`NONE`** (high volume; per doc page 23) |
| **SIPA** (third-party IP allow-listed) | Vendor portals requiring fixed source IP | **Dedicated SIPA AC group** (separate egress IPs) | **SIPA SG** bound to SIPA AC group only | `ON_ACCESS` |
**Why this matters:** the defaults in this skill historically used `health_reporting="ON_ACCESS"` for everything. That is wrong for Discovery (should be `NONE` to avoid probe storms across all communal AC groups) and may be wrong for critical multi-DC apps (where `CONTINUOUS` lets ZPA route users to the closest *healthy* server). Pick the class first, then the rest of the workflow uses the right defaults.
If the administrator is unsure, default to **Standard** and tell them they can re-classify later by updating the segment.
---
### Step 1: Gather Application Details
Collect the following from the administrator:
**Required:**
- Application name
- Domain name(s) or IP address(es) the application runs on
- TCP and/or UDP port(s) (e.g., 443, 80, 8080, 3389)
- Who should have access (users, groups, or departments)
**Optional:**
- Description and purpose of the application
- Geographic location of the application servers
- Whether to reuse existing ZPA resources (connector groups, server groups, segment groups)
- Health check requirements
- Whether CNAME resolution is needed
---
### Step 2: Set Up App Connector Group
Check for existing connector groups or create a new one.
**List existing:**
```text
zpa_list_app_connector_groups()
```text
**Create if needed:**
```text
zpa_create_app_connector_group(
name="<location>-Connectors",
description="Connectors serving <application_name>",
enabled=True,
latitude="<lat>",
longitude="<lon>",
location="<datacenter_or_office>",
country_code="<country>"
)
```text
Save the connector group `id` for the next step.
---
### Step 3: Set Up Server Group
Check for existing server groups or create a new one.
**List existing:**
```text
zpa_list_server_groups()
```text
**Create if needed:**
```text
zpa_create_server_group(
name="<application_name>-Servers",
description="Server group for <application_name>",
app_connector_group_ids=["<connector_group_id>"],
enabled=True,
dynamic_discovery=True
)
```text
Save the server group `id` for Step 5.
---
### Step 4: Set Up Segment Group
Segment groups logically organize application segments. Check for an existing one or create a new one.
**List existing:**
```text
zpa_list_segment_groups()
```text
**Create if needed:**
```text
zpa_create_segment_group(
name="<application_name>-Segment-Group",
description="Segment group for <application_name>",
enabled=True
)
```text
Save the segment group `id` for the next step.
---
### Step 5: Create Application Segment
This is the core resource that defines the application's reachability.
```text
zpa_create_application_segment(
name="<application_name>",
description="<description>",
segment_group_id="<segment_group_id>",
domain_names=["app.internal.example.com"],
tcp_port_range=[{"from": "443", "to": "443"}, {"from": "80", "to": "80"}],
server_group_ids=["<server_group_id>"],
enabled=True,
health_reporting="<from_step_0>",
is_cname_enabled=True
)
```text
**Set `health_reporting` from the Step 0 classification:**
| Class | `health_reporting` value |
|---|---|
| Standard | `"ON_ACCESS"` |
| Sensitive (single-DC) | `"ON_ACCESS"` |
| Sensitive (multi-DC critical) | `"CONTINUOUS"` |
| Global | `"ON_ACCESS"` |
| **Discovery** | **`"NONE"`** |
| SIPA | `"ON_ACCESS"` |
`CONTINUOUS` generates one probe per connector in every bound AC group every interval — avoid it on segments bound to large AC groups.
**Port configuration options:**
For single ports:
```text
tcp_port_range=[{"from": "443", "to": "443"}]
```text
For port ranges:
```text
tcp_port_range=[{"from": "8000", "to": "8999"}]
```text
For UDP (e.g., DNS):
```text
udp_port_range=[{"from": "53", "to": "53"}]
```text
For mixed TCP+UDP:
```text
tcp_port_range=[{"from": "443", "to": "443"}],
udp_port_range=[{"from": "53", "to": "53"}]
```text
Save the application segment `id` for the access policy.
---
### Step 6: Create Access Policy Rule
Grant access to the application for specific users or groups.
First, look up the identity entities to reference in the policy:
```text
get_zpa_scim_group(search="<group_name>")
get_zpa_saml_attribute(search="<attribute_name>")
```text
Then create the access policy rule:
```text
zpa_create_access_policy_rule(
name="Allow <group> to <application_name>",
description="Grants <group> access to <application_name>",
action_type="ALLOW",
conditions={
"operands": [
{
"objectType": "APP",
"values": ["<application_segment_id>"]
},
{
"objectType": "SCIM_GROUP",
"values": ["<scim_group_id>"]
}
]
}
)
```text
**Common action types:**
- `ALLOW` -- permit access
- `DENY` -- block access
- `REQUIRE_APPROVAL` -- require explicit approval before access
---
### Step 7: Verify and Summarize
Verify each resource was created correctly:
```text
zpa_get_app_connector_group(group_id="<id>")
zpa_get_server_group(group_id="<id>")
zpa_get_segment_group(group_id="<id>")
zpa_get_application_segment(segment_id="<id>")
zpa_get_access_policy_rule(rule_id="<id>")
```text
#### Present Summary
```text
Application onboarding complete.
**Application:** <name>
- Domains: app.internal.example.com
- Ports: TCP 443, TCP 80
- Health Reporting: ON_ACCESS
**Infrastructure:**
- App Connector Group: <name> (ID: <id>)
- Server Group: <name> (ID: <id>)
- Segment Group: <name> (ID: <id>)
**Access Policy:**
- Rule: Allow <group> to <name>
- Action: ALLOW
- Granted To: <group_name>
**Resource Dependency Map:**
App Connector Group ─► Server Group ─► Application Segment ◄─ Segment Group
│
▼
Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.