Note: Nintex Apps data centers are located in West US and Australia (AUS). In-region processing of Nintex Apps data is only available in these regions.

Model Conditions

Model conditions determine the appearance of data by limiting the records that are pulled into a model from the external system. They tell models which data to request (or not request) by checking fields specified in the condition against parameters and values also specified. Model conditions essentially filter content before it is pulled into the model.

Use conditions to pull in and display a single record, like that on a detail page. Or use conditions to filter which records are shown within a Table component. Conditions can filter data on the fly when set to a dynamic state. Dynamic conditions can be set to a default on or off. Dynamic conditions that default off can be useful for situations where a condition should wait to receive values from a user interaction, and then those values can trigger the condition to filter the data.

Jump to:

Condition concepts

How does a condition work?

Conditions are made up of the following:

  • Field
  • Operator
  • Value
  • State

Once configured, they behave like so:

  1. The model queries data.

When there's a condition applied to the model, the model filters the returned data.

Here's an example: The company has many client accounts across the world. But Jamie only handles accounts located in the Western United states; she doesn't need to see all company accounts, only those in California, Oregon, and Washington.

The condition would filter the account's billing address (or even the billing) state field for three values (WA, OR, and CA), and only bring account data into the page that matches that criteria.

Server-side and client-side conditions

Some connectors offer both server-side and client-side conditions. This determines where the data is filtered for a model:

  • Server-side: Filtering occurs on the external system before it is returned to the page.
    • Best when working with large amounts of data with complex condition logic; filtering data on the server means the end user’s machine doesn’t have to handle filtering at scale.
    • Server-side conditions support condition logic, allowing for any or all condition rules to apply.
  • Client-side: Filtering occurs at runtime, within the user’s browser.
    • Best when working with fewer records and more active filtering, as client-side filtering doesn’t require additional network requests since it occurs on the end user’s machine.
    • Client-side conditions only support "all" condition logic, meaning all conditions must apply.

Not all connectors handle server-side operations with conditions; REST-based connectors utilize parameters.

Condition logic: Any vs all

Condition logic options are only available for server-side conditions. Client-side conditions can only use "all" logic.

When creating multiple conditions on an object, it’s important to consider whether all conditions should be true for a record to be returned or whether any condition can be true.

When all is selected, a record must meet the criteria specified by every condition within the model. To illustrate this, the logical operator AND is prepended to each condition statement.

When any is selected, a record can meet any criteria and it will be included. To illustrate this, the logical operator OR is prepended to each condition statement.

If you have nuanced filtering needs, consider using a condition group, as each group has its own condition logic.

Manage conditions

To create a condition:

  1. In the Elements panel, click the Models tab.
  2. Click the model.
  3. Click Conditions.
  4. Click either Server-side conditions or Client-side conditions, depending on the desired behavior.
  5. Click Add condition. Once created, conditions appear in a sentence-like format to aid in readability.

To edit a condition:

  1. In the Elements panel, click the Models tab.
  2. Click the model.
  3. Click Conditions.
  4. Click either Server-side conditions or Client-side conditions, depending on where the condition is located.
  5. Beside the condition, click the More options icon.
  6. Click Configure.

To delete a condition:

  1. In the Elements panel, click the Models tab.
  2. Click the model.
  3. Click Conditions.
  4. Click either Server-side conditions or Client-side conditions, depending on where the condition is located.
  5. Beside the condition, click the More options icon.
  6. Click Delete.

Create and configure a subquery condition

If using Result of a subquery as a condition value's type, you can add conditions to that query—known as subquery conditions. This provides filtering on the results of the subquery, helping tailor the values for the "parent" condition.

  1. Click the previously created model condition.
  2. Click Add subquery condition to create a new subcondition to the parent condition.
  3. Configure the condition.
  4. Click Save.

Subquery conditions can also be configured as condition groups.

Condition groups

Condition groups provide a way to nest an additional set of conditions with their own any/all object. You can create sophisticated filtering with a combination of rules using groups.

To add a condition group:

  1. Navigate to the Conditions tab in a model’s details.
  2. Click Add group.

To add conditions to that group, click Add condition within the group’s nested area.

To delete a condition group, click More Options > Delete.

For example, it’s possible to retrieve accounts for review based on several different rule sets using condition groups:

Return Account records that match any of the following conditions:

Return Account records that match all of the following conditions:

The AnnualRevenue field value > 1000000

AND the Rating field value = “Cold”

OR Return Account records that match all of the following conditions:

The LastActivityDate field value > LAST_N_MONTHS:3

AND the Rating field value = “Cold”

With this condition set, records that match either of the condition groups will appear. The record must match all the criteria specified by each group.

Parameters

Closely related to conditions are parameters—model properties that identify the data a request should work with. They define both the endpoint and request structure for REST-based services. Parameters are prescriptive and are usually required to retrieve any data.

This is a key difference from conditions, which are optional filters with changeable values. Parameters (particularly for query operations) are typically required inputs, and their values often remain the same once set.

Parameters are divided into separate operations—the actions that occur to the data retrieved by the model.

To use a parameter, first add it to an operation:

  1. Beneath an operation, click Add parameter. The parameter selection modal appears, listing all available parameters and their descriptions.
  2. Click Add beside the desired parameters.
  3. Click Done.

With the parameter added to the operation, set a value for the parameter:

  1. Click More Options beside the desired parameters.
  2. Click Configure.
  3. Set the parameter’s value.

Controlling parameters dynamically

If a Retrieve operation's parameter must be controlled dynamically after its configured, enable the Control parameter with condition property. When enabled, a condition is auto-generated and synchronized with the parameter. Parameter-related conditions can be seen by navigating to Conditions > Parameter conditions within a model’s details.

You can change the parameter’s value using standard condition actions.

Note: Only Retrieve operation parameters can be controlled dynamically.

Properties

  • Field: The field in the current model to use as a filter. Select using field picker.

  • Operator: The relationship between the field and its value. Standard operators are used.

  • Value: The specific content used by the condition to filter the data.

    Note:  Some content options are not available for every connector.

    • Content:

      • Single specified value: The condition only returns records that meet the specified value.

        • Value: The value that triggers the condition.

      • Multiple specified values: The condition returns records that meet at least one of the several specified values.

        • Values: Values that triggers the condition.

      • Field from another model: Use a field from another model as the condition. This condition links models by setting up a relationship between their fields. There must be at least two models on the page to utilize this content type..

        • Source model: The name of the model.
        • Source field: The field on the source model.
        • If no row in source model, then ...
          • Deactivate this Condition
          • Abort this Model's Query

      • Page/URL parameter value: Returns records that meet the specified page or URL parameter (for example, an id parameter, often designated as id=xxxxxxxxxxxx in the page's URL).

        Note:  This type of condition is required to use a Nintex Apps pages as an override for the Salesforce View, Edit, or Clone actions.

        • Parameter: Indicates the specific parameter to filter by.
        • If this parameter is not provided, then ...
          • Set its value to Blank
          • Deactivate this Condition
          • Abort this Model's Query

        Note:  This condition type is commonly used to pass a record's id into a page or page component. For example, on a detail page that shares information on an account—but also displays that account's contacts and new opportunities—use this condition on the account, contact, and opportunity models to ensure that only a single account is held in the model—and only the contacts and opportunities that are related to it.

      • Nintex Apps user attribute / Connection user attribute: Returns records if the value of a field on the model matches the value of a field on the current user's record in Nintex Apps or in their external system.

        • Nintex Apps user attribute: The value on the current user's record that triggers the condition (usually an ID property). Options include:
          • Default currency
          • First name
          • Last name
          • Email
          • Locale
          • Name
          • Organization ID
          • Organization name
          • Profile ID
          • Profile name
          • Session ID
          • User ID ( default )
          • User name
          • Use role ID
          • User type
          • Is multi currency org

      • Connection user attribute: The value on the current user's record that triggers the condition. Options include:

        • First name
        • Last name
        • Email
        • Full name
        • User ID
        • User name

      • None - blank value: Returns records where the specified field is blank/null.

      • Result of subquery: Create a condition that simulates sub-conditions in SOQL (a semi-join sub-select).

        • Join object: The object to join. For example, Case in this argument: WHERE ID in (SELECT ContactId FROM Case) .
        • Join field: The field to join. For example, ContactId in this argument: WHERE ID in (SELECT ContactId FROM Case) .

  • State:

    • Condition state: This determines whether the condition is activated or deactivated.

      • Always on: This condition is always on and cannot be turned off.
      • Dynamic (Default on) and Dynamic (Default off): The condition can be turned on and off using a filter or action.
        • Condition name: The dynamic condition's label displayed in filters and actions that alter conditions.
      • Always off: This condition is always off and cannot be turned on.