zpa_list_application_segments()zpa_list_segment_groups()```text
**For identity conditions:**
```textget_zpa_scim_group(search="<group_name>")get_zpa_saml_attribute(search="<attribute_name>")```text
**For trusted networks:**
```textget_zpa_trusted_network(search="<network_name>")```text
**For posture profiles:**
```textget_zpa_posture_profile(search="<profile_name>")```text
---
### Step 3: Build Conditions and Create the Rule
```textzpa_create_forwarding_policy_rule( name="<rule_name>", action_type="BYPASS", description="<description>", conditions=<conditions_payload>)```text
The conditions format is identical to access policy rules. See the examples below.
---
### Step 4: Verify
```textzpa_get_forwarding_policy_rule(rule_id="<returned_rule_id>")```text
Present the rule summary including action, conditions, and scope.
---
## Ready-to-Use Examples
### Example 1: Bypass ZPA for a Segment Group
Bypass ZPA tunneling for all applications in a segment group (e.g., video conferencing apps).
**Step 1: Find the segment group**
```textzpa_list_segment_groups()```text
**Step 2: Create rule**
```textzpa_create_forwarding_policy_rule( name="Bypass Video Conferencing", action_type="BYPASS", description="Send video conferencing traffic directly, bypassing ZPA tunnel", conditions=[ { "operator": "OR", "operands": [ { "object_type": "APP_GROUP", "values": ["<video_conferencing_segment_group_id>"] } ] } ])```text
---
### Example 2: Bypass for Specific Users on Trusted Network
When users are on the corporate trusted network, bypass ZPA and go direct.
**Step 1: Look up IDs**
```textget_zpa_trusted_network(search="Corporate_WiFi")get_zpa_scim_group(search="Office_Workers")```text
**Step 2: Create rule**
```textzpa_create_forwarding_policy_rule( name="Direct Access on Corporate Network", action_type="BYPASS", description="Bypass ZPA when on corporate trusted network", conditions=[ { "operator": "OR", "operands": [ { "object_type": "TRUSTED_NETWORK", "entry_values": [ {"lhs": "<corporate_wifi_network_id>", "rhs": "true"} ] } ] }, { "operator": "OR", "operands": [ { "object_type": "SCIM_GROUP", "entry_values": [ {"lhs": "<idp_id>", "rhs": "<office_workers_group_id>"} ] } ] } ])```text
**Logic:** User must be on the corporate trusted network AND be in the Office_Workers group.
---
### Example 3: Intercept All Traffic for Contractors
Force all contractor traffic through ZPA regardless of application.
**Step 1: Look up contractor group**
```textget_zpa_scim_group(search="Contractors")```text
**Step 2: Create rule**
```textzpa_create_forwarding_policy_rule( name="Intercept Contractor Traffic", action_type="INTERCEPT", description="Route all contractor traffic through ZPA for security", conditions=[ { "operator": "OR", "operands": [ { "object_type": "SCIM_GROUP", "entry_values": [ {"lhs": "<idp_id>", "rhs": "<contractors_group_id>"} ] } ] } ])```text
---
### Example 4: Platform-Specific Bypass
Bypass ZPA for specific applications only on Linux and Android devices.
```textzpa_create_forwarding_policy_rule( name="Bypass Dev Tools on Linux/Android", action_type="BYPASS", description="Development tools bypass ZPA on Linux and Android", conditions=[ { "operator": "OR", "operands": [ { "object_type": "APP_GROUP", "values": ["<dev_tools_segment_group_id>"] } ] }, { "operator": "OR", "operands": [ { "object_type": "PLATFORM", "entry_values": [ {"lhs": "linux", "rhs": "true"}, {"lhs": "android", "rhs": "true"} ] } ] } ])```text
---
### Example 5: INTERCEPT_ACCESSIBLE for Hybrid Apps
Use `INTERCEPT_ACCESSIBLE` for applications that may or may not be reachable through ZPA depending on the user's location.
```textzpa_create_forwarding_policy_rule( name="Conditional Intercept for Hybrid Apps", action_type="INTERCEPT_ACCESSIBLE", description="Route through ZPA only if destination is reachable via ZPA connectors", conditions=[ { "operator": "OR", "operands": [ { "object_type": "APP_GROUP", "values": ["<hybrid_apps_segment_group_id>"] } ] } ])```text
**When to use:** The application exists both on the corporate network (reachable via ZPA) and on the public internet. `INTERCEPT_ACCESSIBLE` routes through ZPA if connectors can reach it, otherwise falls back to direct access.
---
### Example 6: Combined SAML + Platform + Country
Bypass ZPA for a SAML-identified group, only on Windows, only from the US.
```textzpa_create_forwarding_policy_rule( name="US Windows Bypass for Finance", action_type="BYPASS", description="Finance team on Windows in the US bypasses ZPA for specific apps", conditions=[ { "operator": "OR", "operands": [ { "object_type": "APP_GROUP", "values": ["<finance_apps_segment_group_id>"] } ] }, { "operator": "OR", "operands": [ { "object_type": "SAML", "entry_values": [ {"lhs": "<saml_group_attr_id>", "rhs": "Finance"} ] } ] }, { "operator": "OR", "operands": [ { "object_type": "PLATFORM", "entry_values": [ {"lhs": "windows", "rhs": "true"} ] } ] }, { "operator": "OR", "operands": [ { "object_type": "COUNTRY_CODE", "entry_values": [ {"lhs": "US", "rhs": "true"} ] } ] } ])```text
**Logic:** App must be in the Finance segment group AND user has SAML group "Finance" AND platform is Windows AND country is US.
---
## Forwarding vs Access Policy Comparison
| Aspect | Access Policy | Forwarding Policy ||---|---|---|| **Purpose** | Who can access apps | How traffic reaches apps || **Actions** | `ALLOW`, `DENY`, `REQUIRE_APPROVAL` | `BYPASS`, `INTERCEPT`, `INTERCEPT_ACCESSIBLE` || **Evaluated when** | After forwarding decision | Before access decision || **Tool** | `zpa_create_access_policy_rule` | `zpa_create_forwarding_policy_rule` || **Condition types** | Same | Same |
**Evaluation order:** Forwarding policy is evaluated first (determines routing), then access policy is evaluated (determines authorization).
---
## Edge Cases
### Bypass with No Conditions
A forwarding rule with no conditions applies globally:
```textzpa_create_forwarding_policy_rule( name="Global Bypass", action_type="BYPASS", conditions=[])```text
This bypasses ZPA for ALL traffic, which is almost never desired. Always scope with conditions.
### Conflicting Forwarding and Access Rules
If traffic is bypassed by a forwarding rule, the access policy rule is never evaluated for that traffic. Be careful not to bypass traffic that requires access policy enforcement.
### Listing Existing Forwarding Rules (opt-in)
Do **not** pre-list forwarding rules before every create. New ZPAforwarding rules are appended at the end of the policy by default;pre-listing adds a round trip, gives no useful information for thetypical case, and invites fan-out retries when the list comes backempty on a fresh tenant.
Run the listing **only** when the admin explicitly asks about ordering,duplicate names, or wants to inspect existing rules:
```textzpa_list_forwarding_policy_rules()```text
---
## Quick Reference
**Tools used:**
- `zpa_list_application_segments()` -- find application segments- `zpa_list_segment_groups()` -- find segment groups- `get_zpa_scim_group(search)` -- look up SCIM group IDs- `get_zpa_saml_attribute(search)` -- look up SAML attribute IDs- `get_zpa_trusted_network(search)` -- look up trusted network IDs- `get_zpa_posture_profile(search)` -- look up posture profile UDIDs- `zpa_create_forwarding_policy_rule(name, action_type, conditions)` -- create the rule (no pre-flight needed)- `zpa_list_forwarding_policy_rules()` -- **only** when the admin explicitly asks about ordering or wants to inspect existing rules- `zpa_get_forwarding_policy_rule(rule_id)` -- verify the rule
**Condition logic:**
- Multiple condition blocks = AND (all must match)- Multiple entry_values within a block = OR (any can match)- Separate condition blocks per object type
**Actions:** `BYPASS`, `INTERCEPT`, `INTERCEPT_ACCESSIBLE`
