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.

Display logic

Display logic allows page builders to control how components and their elements are rendered, enabled, and styled, , based on specific conditions. This feature provides flexibility in determining how and when data is displayed. Display logic statements are made up of one more conditions and can be reused across multiple components, allowing a single statement to trigger display state updates on multiple components. Display logic is available as a tab in the Elements panel, providing a central location for managing these statements.

Jump to:

Types of Display logic
Best practices when using Display logic
Configure Display logic statements
Properties

Types of Display logic

Conditional rendering: A component or element is only displayed (or rendered) if specific conditions are met; otherwise, it stays hidden. This allows you to:
- Hide components until they are needed, making the workflow clearer and more focused. For example, if an account's contact prefers email, phone fields are hidden to prevent the representative from mistakenly calling the customer.
- Display or hide data based on the user's role privileges,. For example, if the account type is partner, the app displays a partner information tab in a Tab Set.
- Guide users through workflows, providing just-in-time information as they progress through each step. For example, if the user is a manager, an account profitability table is displayed. For non-managers, the table remains hidden.
Conditional enabling: A feature, such as a button, is displayed but remains disabled until the specified conditions are met. For example, a button might appear grayed out until the user fills out all the fields on a page
Conditional styling: The style variant of a component or element changes when the defined conditions are met. For example, you can use conditional styling to:
- Change form fields to green after they have been completed correctly.
- Visually indicate a change in the app's state.
- Highlight a button once it is conditionally enabled.

Conditional opening: Determines whether a component feature will load in an open or closed state. For example, it can be used to load an Accordion component with specific sections either opened or closed when the page loads.

Best practices when using Display logic

Conditional rendering is a useful tool for controlling what is displayed based on user site permissions, but it should not be used as a replacement for strong security settings.
Clearly define the reason for hiding or disabling a feature. Consider the benefits and potential downsides. Always provide an informative message when a feature is disabled to guide the user.
If your statement's condition values are too narrow in scope, the elements may rarely render or enable. This can result in hiding or disabling too many elements on the page.
Some elements, like buttons and fields, can either be conditionally rendered or conditionally enabled. To decide which option is best:
- Conditionally render the element if it’s better for the user experience to hide it until it's needed. If the element would distract users from their workflow, hiding it is the better choice.
- Conditionally enable the element if it's helpful for the user to see it but not interact with it, allowing its disabled state to act as a reminder for what needs to be completed in the workflow.
Limit the number of render and enable conditions on a page, as too many can make the page overly complicated for users, harder to maintain, and slower to load.
If the condition's Source type requires a Source model, ensure you select the correct one.
When using conditional rendering on a button within an Ink Button Set , avoid rendering the primary action button conditionally, as this can lead to a confusing user experience.
Clearly define the hierarchy of your conditional style rules. When a component or its elements have multiple style conditions, they are evaluated in the order of creation. Once the first condition evaluates as true, it is applied, and no further conditions are evaluated.

Configure Display logic statements

Click the Display logic tab in the Elements panel.
Click Add a statement.
Provide an informative Name and Description for the statement.
Click Create. The Elements panel expands to show the statement builder.
Determine when the statement should activate:
- All conditions are met
- Any conditions are met
Click Add condition or Add group to add a condition or condition group, respectively.

To configure a condition:

Set the source type, which determines what the condition should evaluate. Each source displays a different set of properties to configure. See the Properties section below for more information.
Set how to to evaluate a chosen field/property. This typically involves:
- Selecting a field/property
  - Setting an operator
  - Setting an expected value for the field/property
Click Apply to create the condition.

Conditions and condition groups

There are two ways to set conditions for statement’s

As individual conditions
As condition groups, which group together a set of conditions as a single rule.

For complex rules it can be useful to combine conditions and conditions groups. Consider this example: You want to display a warning banner on an incident with the following stipulations: - It’s a security incident or a system failure (Handled with single conditions) - The incident has been open for 72 hours and the status is still open (Handled as a condition group )

A display logic statement for this example may look something like this:

Activate if any of the following conditions are met:

the Type field on the Incident_Example model = “Security”
or the Type field on the Incident_Example model = “System failure”
or Activate if any of the following conditions are met:
- the lastUpdated field on the Incident_Example model = N_DAYS_AGO:3
  - and the Status field on the Incident_Example model = “Open”

Apply display logic to components or elements

All display logic features available to a component or element are listed in the Display logic section of the properties panel. Depending on the component or element, the following options may be available:

Render if..
Enable if..
Open if..
Style variants

To set attach a display logic statement to the option:

Click the variation Add logic for that option. The logic statement selector appears.
Click the Logic statement field to open the selector.
Click the statement you wish to apply or click Create new display logic to create a new one and apply it.
- Any display logic statements created this way will receive a default name based on the logic type and component.

Properties

Properties available for setting conditions

Source type: The value or property being evaluated for rendering or enabling the element.
- Model field value: Evaluates a value within a specified model field.
  - Source model: The model that contains the specified field.
  - If no rows in a model: Defines behavior if the model is empty.
    - Ignore this condition (default): Ignores this condition (treats it as true) and continues to evaluate following conditions.
    - Skip other conditions, and render/enable/use this style variant: Stops evaluating other conditions and renders/enables the element or applies the style variant.
    - Skip other conditions and don’t render/enable/use this style variant: Stops evaluating other conditions, and the element is not rendered, enabled, or styled.
  - Field: The field in the model to evaluate.
  - Operator: Select from standard Nintex Apps operator.
  - Content: Defines the values to be evaluated.
    - Single specified value: The single value that triggers the condition.
    - Multiple specified values: A set of values that trigger the condition.
    - Page/URL parameter value: The page or URL parameter that must match for the condition to trigger.
    - Nintex Apps user attribute: The user attribute that triggers the condition.
    - Session variable: A session variable that corresponds to a SAML attribute from an identity provider.
    - None: A blank value.
    - Result of a formula: Evaluates a formula and triggers the condition if the result is true.
  - Model property: Evaluates a property of the specified model.
    - # of rows in model
    - Doesn’t have data rows
    - Has data rows (default)
    - Has unsaved changes
    - Model label
    - Model plural label
  - Row property: Evaluates a property of a row in the specified model.
    - Source model: The model being evaluated.
    - Row property: The property of the row to evaluate.
      - Has unsaved changes
      - Is a new record (default)
      - Is an existing record in the database (default)
      - Is an unsaved clone of an existing record (default)
      - Is marked for deletion (default)
  - Page/URL parameter value: Evaluates a specified page or URL parameter.
    - Parameter name: The name of the parameter to evaluate.
    - Operator: Choose from standard Nintex Apps operators.
    - Content:
      - Single specified value: The value that triggers the condition.
      - Multiple specified values: A set of values that trigger the condition.
      - Nintex Apps user attribute : The user attribute to be evaluated.
      - None: Use for a blank value.
      - Result of a formula: Evaluates a formula to determine if the condition is met.
        
        Formula: The formula used for evaluation.
  - Running user attribute: Evaluates a property of the running user.
    - User attribute: The attribute to be evaluated.
    - Operator: Choose from standard Nintex Apps operators.
    - Content:
      - Single specified value: The value that triggers the condition.
      - Multiple specified values: A set of values that trigger the condition.
      - Page/URL parameter value: The page or URL parameter the attribute must equal to trigger the condition.
      - Nintex Apps user attribute : The user attribute to be evaluated.
      - None: Use for a blank value.
      - Result of a formula: Evaluates a formula to determine if the condition is met.
        
        Formula: The formula that triggers the condition when evaluated as true.
  - Running user has permission: Evaluates whether the running user has a specified permission.
    - Permission namespace: The NLX site that contains the permission.
      
      Note: The only available namespace is "Skuid."
    - Permission name: The type of platform site permission the user has.
      - Configure self
      - Configure site
    - Is:
      - True (Allowed)
      - False (Not Allowed)
    - Snippet returns true: Runs a JavaScript snippet. If the snippet returns true, the condition is met.
      - Snippet name: The name of the snippet to be executed.
    - Viewport width: Evaluates the visible width of the page.
      - Operator: Choose from standard Nintex Apps operators.
      - Viewport width: The specific size of the visible area.
        
        Note: The viewport size depends on the device and is typically smaller on mobile phones than on computer screens. Use this property to adjust the user experience for smaller screen areas.
    - Connection user attribute: Evaluates an attribute of the user’s account within a specified connection.
      - Connection: The connection to use.
      - Connection user attribute: The attribute to be evaluated. Options include:
        
        User ID
        
        Organization ID
        
        Business Unit ID
        
        Role Names
        
        Role IDs
      - Operator: Choose from standard Nintex Apps operators.
      - Content:
        
        Single specified value: The value that triggers the condition.
        
        Multiple specified values: A set of values that trigger the condition.
        
        Page/URL parameter value: The page or URL parameter that must be met.
        
        Nintex Apps user attribute: The user attribute that triggers the condition.
        
        None: Use for a blank value.