---
title: "Creating and editing Conditions in the Admin UI"
slug: "configure-conditions-v6-6"
description: "Control network resource access in Entitlements with dynamic claims, user interactions, and advanced scripting for enhanced security and flexibility."
updated: 2026-02-06T20:52:56Z
published: 2026-02-06T20:52:56Z
canonical: "support.appgate.com/configure-conditions-v6-6"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.appgate.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure conditions

Conditions define criteria and user actions used to control when network resources in Entitlements can be accessed. Review the [Before you start](/v1/docs/conditions-v6-6) section before configuring.

## Actions

The Actions menu in the **Add or Edit Condition** page allows you to clone the Condition or [test access](/v1/docs/checking-access-rights-v6-6) based on the settings below.

## Add/Edit Condition

To create or edit conditions, you will configure the access criteria and re-evaluation settings. Select **+Add** to create a new Condition or select an existing Condition to edit.

### Access Criteria

To configure the access criteria for a condition, enter values in the following fields:

- ***Setting Modes.*** List mode provides three options to configure the criteria that need to be true in order for access in an Entitlement to be allowed. Selecting a claim will automatically display the relevant parameters.

- *Switch to Script Mode.* By using the script editor it is possible to edit existing expressions or to create your own. The JavaScript engine is run in a sandbox preventing any file system access, however it is possible to make external calls using:

> [!NOTE]
> **NOTE**
> 
> Script mode is available for very advanced use cases. However this may break compatibility with the other three modes.

- HTTP PUT
- HTTP POST
- HTTP GET
- HTTP DELETE

This would for instance allow a value to be passed to an external system for validation as part of the expression. Refer to [access criteria script](/v1/docs/access-control-modes-v6-6#access-criteria-scripts) for more information on scripting.

- ***Criteria Combining Mode.*** Criteria expressions have three different combining modes (without using scripts):

- <all criteria below must be true> - a logical AND of different criteria needs to equate to true
- <at least one of the criteria below must be true> - a logical OR of different criteria needs to equate to true
- <Criteria are met according to custom logic> - a simple Boolean expression comprising a number of different criteria needs to equate to true

[Condition based access](/v1/docs/access-control-modes-1) provides more information and examples

- ***Criteria.*** By selecting criteria that include dynamic claims (that change during a session), you can create access criteria expressions that enable AppGate ZTNA to respond to changes in a timely manner. For example, clientSrcIP claim can be used to remove access to protected resources when the user leaves the office to work from home. Conditions can include multiple criteria, so you will need to decide how to combine the access criteria. There is also a Script mode for advanced use cases.
  - *Type - User Actions****.*** In the *Type* dropdown there are three user response claims under **User Actions**: *Provided MFA*, *Provided Reason*, or *Password*. Unlike all other claims, which are hard-coded or pre-configured (for instance within the identity provider), user interaction names are defined within the Condition itself. When Configured with a claim suffix (name) and time period (if required) then a new user response claim (using that name) is automatically created.

| Type | Claim Suffix (Name) | Minutes (Time window) | Internal Claim Name | Criteria Check Method Used |
| --- | --- | --- | --- | --- |
|  | The claim name that refers to this occurrence of the user interaction | Time window during which the claim shall evaluate to true | The internal user response claim generated from the given claim suffix (name) | Matching criteria check method used to evaluate if the claim is true or false |
| Provided MFA | i.e., general | i.e., 60 | user.otp.general | claims.user.hasOtp("general", 60) |
| Retyped Password | i.e., finance | i.e., 60 | user.password.finance | claims.user.hasPassword("finance", 60) |
| Provided Reason | i.e., github | n/a | device.reason.github | claims.device.hasReason("github") |

[User response claims](/v1/docs/applying-access-controls-user-interactions-v6-6) gives more details and examples about the built in check method used and how this ties into the naming of these types of claims.

- *Other claim types****.*** As you build an expression you will be prompted for the necessary parameters according to the claim selected.

- **User claims example:**

**"groups match"**: use this option to check for membership of an LDAP group.

The match operator uses exact match; while testing the LDAP "groups" claim with contains operator, you need to provide the whole FQDN of the group name. For example:

`CN=group3,OU=sweden,DC=cryptzone,DC=com", "CN=group4,OU=sweden,DC=cryptzone,DC=com`

We do not recommend using partial matches for security reasons but you can do this in the Javascript editor.

You can flatten "groups" claim to a single string: `var all_groups = claims.users.groups.toString()` then check the group name `var match= all_group.indexOf('CN=Developers,') &gt; -1;`

Note the trailing comma in the example, make sure to include trailing comma for security reasons so there are no un-intentional matches like `CN=Developers Inactive, OU= vs CN=Developers, OU=..`

- **Device claims example:**

"**os.family**": use this option to include devices with a particular OS e.g. windows.

"**isFirewallEnabled**": use this option to check for a device firewall

> [!NOTE]
> NOTE
> 
> Any device claims or on-demand claims which return yes/no, true/false, etc will be evaluated as a string. Any values that should NOT be treated as a string need to be handled using <script returns true> mode.

- *System Claims example:*

- "**clientSrcIP**": use this option to look for an exact IP address for connecting clients e.g. 19.34.6.120.

You can include multiple user interactions in your access criteria, for example: if you want track why a user requires access, you can combine <Provided Reason> and <Provided MFA> to access a protected resource. [Claims in detail](/v1/docs/claims-in-detail-v6-6) provides details about all the different access criteria available.

- ***Custom Logic.*** Only present when using ***<Criteria are met according to custom logic>*** mode. The numbered Criteria (set above) can be combined in a simple Boolean expression.

![Custom logic operators for combining conditions in a search query interface.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/ag65-custom_logic(1).png?sv=2026-02-06&spr=https&st=2026-10-26T23%3A25%3A55Z&se=2026-10-27T00%3A25%3A55Z&sr=c&sp=r&sig=1s6D7wnw0Yg1lk1cW1gtdgEepP8Ydjbf5iVMqmQHjWw%3D)

When using 'Custom Logic' then the only operators that are allowed are: AND OR NOT ( ). When removing access criteria from an expression you must delete (edit) the numbered line item and edit the Custom Logic to remove any reference to the numbered item or it will not be removed from the underlying JavaScript expression.

- ***User Actions.*** Used to display a message or a user interaction prompt on the user's device when the access criteria expression fails.

> [!NOTE]
> **NOTE**
> 
> If the access criteria include <Provided MFA>, <Retyped password>, or <Provided reason> claim(s), you must enter the same claim suffix for it to work correctly.

- Example 1: if you have set an access criteria <Provided reason> with the claim suffix (name) of name1 then there must a matching <Provide reason> user interaction with a user response claim suffix of name1 - this enables the user to enter the required reason.
- Example 2: if you have set an access criteria <Retyped password> with the claim suffix (name) of pass1 every 120 minutes then there must be a matching <Password> user interaction with a user response claim suffix of pass1 with message "Please enter your password".

Complete the required fields:

- *Type of Interaction.* Select the type of user interaction required:

- Display Message
- Require MFA
- Provide Reason
- Password

Then fill any additional fields:

- **Message***.* Enter the text message to be displayed to the user. This should help explain to the user what has happened and the action required. Remember users may have more than one User Interaction configured so it is very important to be VERY clear about which one (or Collective) this is. Limited HTML and variables can be used. See [Messaging the user](/v1/docs/messaging-the-user-v6-6) for details.
- **Radius***.* If you are using a RADIUS identify provider, you can use %RADIUS_MESSAGE% to use the reply-message (24) from the RADIUS server. For example: Require MFA named <string> with text "%RADIUS_MESSAGE%"
- **Claim Suffix***.* This will set a user response claim with this name. The same name should be used in the related access criteria. If you are configuring MFA at sign-in and also plan to use an MFA user interaction, then if you use the same [user response claim suffix](/v1/docs/applying-access-controls-user-interactions-v6-6#user-response-claims) for both - you can avoid the user having to perform MFA twice over a short period of time.
- **MFA Provider***.* Select the MFA provider used to validate the user interaction. The default OTP provider is shown by default.
- **Identity Provider***.* Select the Identity Provider used to validate the user's password. Defaults to the one used at sign in.

- ***Multiple User Actions.*** You can add multiple user interactions and select between one of these or all of these having to be performed by the user. For one of these; the Client will display the first user interaction with any related prompt/message and provide a link to a page where all the configured user actions are listed in the order set in the admin UI.

For all of these; the Client will display the first user interaction with any related prompt/message and then the next etc in the order set in the admin UI. The up/down arrows allow the list to be reordered.

![User actions required for MFA setup with claim suffix and provider details listed.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/access_conditions_criteria.png?sv=2026-02-06&spr=https&st=2026-10-26T23%3A25%3A55Z&se=2026-10-27T00%3A25%3A55Z&sr=c&sp=r&sig=1s6D7wnw0Yg1lk1cW1gtdgEepP8Ydjbf5iVMqmQHjWw%3D)

### Re-Evaluation

Access criteria expressions can be re-evaluated to enable AppGate ZTNA to respond to changes in a timely manner. Complete the following fields to configure re-evaluation settings:

- ***Periodic Re-Evaluation (UTC).*** The Gateway will re-evaluate a user's claims periodically. Mainly required when using password and MFA user interactions to check if the related claims are still valid. This option forces a periodic re-evaluation on the hour, every 15 minutes or every 5 minutes. For many Conditions there is no typical use case for using this option as the Gateway knows when to re-evaluates a user's Entitlements. By example: device claims are checked every 5 minutes and re-evaluated if changed. There are two situations where periodic evaluations might be required:

- with user interactions where the life time of the claim is set to less than the Claims token life time. A periodic check is required to see if these have expired yet.
- with Conditions that require periodic checking: i.e. seeing if an external system is still reporting that it is doing backups.

For more information about the use of periodic re-evaluation times, refer to: [Real-time re-evaluation](/v1/docs/real-time-reevaluations-v6-6#periodic-reevaluation-utc)

- ***Time of Day for Re-Evaluation (UTC).***The Gateway will re-evaluate a user's claims at these times. Required if the access criteria includes a temporal element such as 'only after 17:00'. This option allows you to force re-evaluation at a particular fixed time of day based on UTC. For many Conditions there is no typical use case for using this option as the Gateway knows when to re-evaluates a user's Entitlements. There are 2 situations where a specific time based re-evaluation might be required:

- used in conjunction with a particular time-based Condition such as requiring all users to be disconnected ahead of a server backup.
- with Conditions that need to be evaluated at a specific time.

For more information about the use of specific re-evaluation times, refer to: [Real-time re-evaluation](/v1/docs/real-time-reevaluations-v6-6#time-of-day-for-reevaluation-utc)