Display Logic

Skuid’s display logic feature allows page builders to control how—and when—data is displayed to end users, using conditional rendering and conditional enabling. Conditional refers to the criteria set by the page builder.

  • With conditional rendering, criteria must be met for the component or element to display (or render), otherwise it is hidden.
  • Conditional enabling displays a feature (such as a button), but disables it until the designated conditions are met.

Types of Display Logic

Imagine an app that gives members of a customer success team access to information about their accounts.

Use conditional rendering to:

  • Hide components until they are needed by the user, to make the desired workflow obvious.
  • Display (or hide) data based on the user’s privileges.
  • Step the user through a workflow, providing just-in-time information as they progress.

A few examples:

  • If the account’s contact prefers email, phone fields are not displayed. This means the rep can’t mistakenly phone the customer when an email is more welcome.
  • If the account type is “partner,” the app displays a partner information tab in a Tab Set.
  • If the end user is a manager, the page includes the account profitability table. (If the end user is not a manager, the table isn’t displayed.)

On the other hand, Conditional enabling might be used to display a button that is greyed out until the user performs certain actions.

What can be conditionally rendered?

All components except for the Search component and the Chatter Feed (Skuid on Salesforce only) component can be conditionally rendered.

The following elements within a component can also be conditionally rendered:

  • Buttons in the Button Set, Wizard, and Header
  • Fields in the Table and Form
  • Navigation items in the Navigation components and the Masthead
  • The logo in a Masthead
  • Tabs in Tab Set, Tab Container, and Accordion
  • Sections in a Form
  • Row, mass, and global actions in a Table component.

What can be conditionally enabled?

Elements that can be conditionally enabled—displayed but not activated until conditions are met—include:

  • Buttons in the Button Set, Wizard, and Header
  • Fields in the Table and Form

Using Display Logic

Both types of display logic (conditional rendering and enabling) rely on established conditions: criteria that determine whether or not the component or element displays (or is activated) so that end users can interact with it.

Configure a render condition on a component or element

Start with a page that has components attached to a working model.

  • Select the component (or element) you want conditionally render.
  • Determine the Render If… criteria.
  • Click add Add new Render Condition to create one (or more) conditions that Skuid will evaluate to determine whether or not to render the component.
    • Configure each condition, starting with the Source Type, which in turn determines which other properties are available for the condition.

Selecting the source type [[]]

There are a number of different Source Types (the type of value or property the condition evaluates) to choose from. How do you choose the one that’s best for your needs?

  • If the rendering/enabling is driven by data—specific criteria in the data model—the Model field value, Model property, or Row property are good places to start.
  • If the rendering/enabling is driven by user privileges— some users can see the content, others cannot—build the condition on Running User attribute, Running User has permission, or Data Source user attribute.
  • If the rendering/enabling is driven by changes in the page environment—choices that the end user makes on the page—try Model or Row property.

Configure an enable condition on a component element

The process for creating an enable condition is identical to that for creating a render condition: click the field or button you want to conditionally enable, select the Enable If … criteria, and configure the desired condition (or conditions).

Best Practices When Using Display Logic

  • Conditional rendering is a valuable tool to limit what is displayed to different user profiles, but it’s not a substitute for strong security settings.
  • Be clear about the reason to hide or disable the feature. What’s the benefit? What are the downsides? Are you helping the users—or just irritating them? Be sure to write an informative Message to show when disabled to help guide the user.
  • Note if the values for your conditions are too narrow in scope, there will be few situation where the elements will render or enable. This may result in hiding/disabling too many things on the page.
  • Some elements (for example, Buttons and Fields) can be conditionally rendered or conditionally enabled. How do you decide which is the better option?
    • Would it be best for the end user if the element was hidden and only appeared as needed? If an element would only serve to distract a user from an intended experience or workflow, conditionally render it.
    • Would it be more helpful if the user could see the element—but not access it—letting the element’s disabled presence serve as a reminder for what needs to be completed inf the workflow? Conditionally enable it.
  • Limit the number of render/enable conditions on a page. Too many conditions make the page:
    • too complicated for the user
    • too complex to maintain
    • too slow to load
  • If the Source Type for the condition requires a source model, make sure to select the correct one.
  • Using conditional rendering on a button that’s part of an Ink button group? Don’t conditionally render the primary action button for that group—this may create a confusing user experience.

Properties

Display Logic tab [[]]

Render Conditions [[]]

These conditions govern when an element or component will display.

  • Render if: The conditions that must be met to enable the element’s display.

    • All Conditions are met
    • ANY Conditions are met
    • Custom Logic is met
      • Condition Logic: The custom logic for grouping and applying one or more conditions.
  • If hidden, Model field changes should be: (only available on Field rendering tabs) If the field is hidden by conditional rendering, this property determines whether any changes made to this field (via Action Framework or JavaScript) are saved in the model, or canceled.

    Note

    Depending on the needs of your org, it could be bad user experience to update fields without direct user input especially when that user may be unaware of they are doing so.

    • Retained in Model (the default)
    • Cancelled

Enable Conditions [[]]

These conditions govern when a displayed element may or may not be enabled for use.

  • Enable if: The model conditions that must be met to enable the field’s editing.
    • All Conditions are met
    • ANY Conditions are met
    • Custom Logic is met
      • Condition Logic: The custom logic for grouping and applying one or more conditions.
  • Message to show when disabled: A brief explanation for why the field is disabled.

For both render and enable conditions [[]]

Click add Add new Render Condition or Add new Enable Condition and then customize:

  • Source Type: The value or property being evaluated to determine whether an element is conditional rendered/enabled.

    • Model field value: The condition evaluates a value located in a model field.

      • Source Model: The model where the specified field is located
      • If no rows in Model: Determines what happens if the model is empty.
        • Ignore this Condition: (Default) Ignores this condition (assumes it to be true) but evaluate any following conditions.
        • Skip other Conditions, and render: No conditions are evaluated; the element renders/enables.
        • Skip other Conditions and don’t render: No conditions are evaluated; the feature doesn’t render.
      • Field: The field in the model to be evaluated.
      • Operator: Standard Skuid operators are available.
      • Content:
        • Single specified value
          • Value: The value that triggers the condition.
        • Multiple specified values
          • Values: Values that triggers the condition.
        • Page/URL parameter value
          • Parameter: The page or URL parameter the field must equal to trigger the condition.
        • Skuid user attribute
          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value
    • Model property: The condition evaluates a property of the model.

      • Source Model: The specified model.
      • Model Property: The model property that triggers the condition:
        • # of rows in Model
        • Doesn’t have data rows
        • Has data rows (default)
        • Has unsaved changes
        • Model Label
        • Model plural label
    • Row property: The condition evaluates a property of a row on the model.

      • Source Model: The specified model.
      • Row Property: The property of the row that triggers the condition:
        • Has unsaved changes
        • Is new record (default)
        • Is existing record in database (default)
        • Is unsaved clone of existing record (default)
        • Is marked for deletion (default)
    • Page/URL Parameter value: The condition evaluates a page or URL parameter.

      • Parameter Name: The specific parameter.
      • Operator: Standard Skuid operators are available.
      • Content:
        • Single specified value
          • Value: The value that triggers the condition.
        • Multiple specified values
          • Values: Values that triggers the condition.
        • Page/URL parameter value
          • Parameter: The page or URL parameter that triggers the condition.
        • Skuid user attribute
          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value
    • Running User attribute: The condition evaluates a user attribute.

      • User Attributed: The specific user attribute.
      • Operator: Standard Skuid operators are available.
      • Content:
        • Single specified value
          • Value: The value that triggers the condition.
        • Multiple specified values
          • Values: Values that triggers the condition.
        • Page/URL parameter value
          • Parameter: The page or URL parameter the attribute must equal to trigger the condition.
        • Skuid user attribute
          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value
    • Running User has permission (Platform only): The condition evaluates whether the Platform user has a specified permission.

      • Permission Namespace: The Skuid Platform site where the permission is located.

        Note

        Currently, the only namespace available is “Skuid.”

      • Permission Name: The type of platform site permission the user has.

        • Configure Self
        • Configure Site
      • Is:

        • True (checked as Allowed)
        • False (checked as Allowed)
    • Snippet returns true: The condition runs a JavaScript snippet. If the snippet runs, and returns a result of True, the condition renders.

      • Snippet Name: The name of the snippet.
    • Data Source user attribute: The condition evaluates an attribute of the user’s account within the specified data source.

      • Data Source: The data source to use.
      • Data Source user attribute: The attribute of the data source that triggers the condition. Choose from:
        • User Id
        • Organization Id
        • Business Unit Id
        • Roles Names
        • Role Ids
      • Operator: Standard Skuid operators are available.
      • Content:
        • Single specified value
          • Value: The value that triggers the condition.
        • Multiple specified values
          • Values: Values that triggers the condition.
        • Page/URL parameter value
          • Parameter: The page or URL parameter the attribute must equal to trigger the condition.
        • Skuid user attribute
          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value