Display Rules

What You'll Learn

You'll learn how display rules work across different element types in Knack, what actions are available on each, and how to use them to create responsive forms and views. This article also covers rule types, precedence, common pitfalls, and the limits of what display rules can reference.

What are Display Rules?

Display rules are conditional rules added to elements on a page. They control field visibility, apply formatting, and change labels based on values on the current record or form inputs. Display rules make your forms and views responsive so users only see what's relevant to them.

Display rules are configured per element. The rules available, and the actions they can trigger, depend on which element type you're working with.

⚠️

Display rules are a user experience feature, not a security feature

Display rules run in the browser. Hidden field values are still sent to the browser and still appear in exports and API responses. See Display Rules and Data Security for details.

Which Elements Support Display Rules?

Not all elements support display rules, and the ones that do have different available actions. Use this table to find what's available on each element type.

📘

List elements

If you need conditional formatting or visibility on a list view, you'll need to use a different element type. List elements do not support display rules of any kind.

When Display Rules Evaluate

Display rules check their conditions in two scenarios:

• Page load. All rules evaluate when the element first loads.
• Field changes. Rules re-evaluate when users modify form inputs.

On forms, this means rules respond in real time as users enter data. On details and table elements, rules evaluate based on the record values at the time the page loads.

What Display Rules Can and Cannot Reference

Display rules can only reference fields on the same record the element is working with. Understanding this scope is the key to knowing when display rules will work and when you need a different approach.

Display rules can reference:

• Any field added to the current form, details element, or table element
• Fields on the same record, including fields you've hidden with another display rule (hidden fields still exist and can trigger conditions)

Display rules cannot reference:

• Fields on a parent or connected record
• Fields from any other table, even one that's directly connected
• Values from other pages or elements

⚠️

Common mistake: referencing a connected record's field

Trying to show or hide a field based on a value from a connected parent record will not work. The value lives on a different record, so the display rule has no access to it.

How to Reference a Connected Value

If you need logic based on a value from a connected record, first bring that value into the current record:

• Text Formula field. Pull the connected field's value into the current record as a read-only field. Once it exists on the current record, display rules can reference it.
• Record Action. After the form submits, use a Record Action to copy the connected value into a field on the current record for future use.

Display Rules on Form Elements

Form display rules control field visibility and labels during data entry. They're the most dynamic of the display rule types because they respond to user input in real time.

Available Actions

Dynamic vs. Standard Rules

Form display rules come in two flavors. Pick one approach per field and stick with it.

Dynamic Rules (Dynamically Show, Dynamically Hide)

• Automatically reverse when conditions change
• Best for responsive forms where fields should appear and disappear based on live user input
• Evaluate in sequence, with the last matching rule taking precedence

Standard Rules (Show, Hide)

• Do not reverse when conditions change
• Best for one-way state changes (once shown, stays shown)
• Evaluate in sequence, with the first matching rule taking precedence

⚠️

Don't mix rule types on the same field

Dynamic rules always override standard rules if both apply to the same field. For predictable behavior, use one type per field.

Hidden Fields Do Not Submit Data

When a form display rule hides a field, that field's value is not submitted when the form is saved. This is expected behavior, but it can cause confusion when a user sees a value populated on the form, a rule hides the field, and the value disappears from the record on submit.

If you need a field's value to be submitted but not shown to the user, consider using a Record Action to set the value on submission instead of putting it on the form.

Practical Example: Job Application Form

A job application form where different positions trigger different follow-up questions.

• Condition: Position field equals "Software Developer." Action: Dynamically Show "Programming Languages" field.
• Condition: Position field equals "Sales Rep." Action: Dynamically Show "Previous Sales Experience" field.

As the user changes the Position selection, the relevant follow-up field appears and the others hide automatically.

Display Rules on Details Elements

Details display rules apply conditional formatting and control value visibility on a record's detail view. They're configured per field within the Details element.

Available Actions

Practical Example: Conditional Late Fee Display

On an invoice detail view, hide the Late Fee field when the due date hasn't passed yet.

• Condition: Due Date is before today
• Action: Hide the Late Fee value (default behavior)
• Condition: Due Date is after today
• Action: Show the Late Fee Value

Display Rules on Table Elements

Table display rules apply conditional formatting to table cells. They're configured per column in Column Settings. Search Result tables work the same way — display rules live under column settings for each column in the results table.

Available Actions

Practical Example: Project Status Tracking

Visually distinguish project status in a table view.

• Condition: Status equals "Complete." Action: Green background, checkmark icon, bold text.
• Condition: Status equals "Overdue." Action: Red background, warning icon, italic text.
• Condition: Status equals "Urgent." Action: Red background, warning icon.

Managing Multiple Rules

Rule Order and Precedence on Forms

On forms, rules evaluate from top to bottom. How precedence works depends on the rule type:

• Dynamic Rules. All rules evaluate in sequence. The last matching rule takes precedence. Place general conditions first and specific conditions last.
• Standard Rules. All rules evaluate in sequence. The first matching rule takes precedence. Place specific conditions first and general conditions last.
• Mixed Rule Types. Dynamic rules override standard rules on the same field.

Organization Best Practices

• Use one type of rule per field when possible (all dynamic or all standard)
• Avoid redundant or conflicting conditions
• Keep the list of rules short. If you have many rules on one element, check whether the logic can be simplified by changing the underlying field types or using conditional rules on the data tab instead.

Notes and Troubleshooting

Hidden form fields don't save data. This is expected behavior. If you need the value submitted without showing it to the user, use a Record Action instead.

Hide and Show rules don't reverse, they are static. This is by design. To get reversing behavior, switch to Dynamically Show or Dynamically Hide.

Dynamic and static rules conflict. Dynamic rules always win. Don't mix types on the same field.

Rules don't fire on connected field changes. Display rules only evaluate on page load and on changes to fields on the current form. If you need logic based on a connected record's value, bring that value into the current record first using a Text Formula field or Record Action.

List elements can't use display rules. If you need conditional formatting or visibility on a list, use a different element type.

When to Use Display Rules and When Not To

Display rules are the right tool for shaping the user experience. They're not the right tool for protecting data.

Good uses:

• Showing or hiding fields based on form selections
• Reducing visual clutter by hiding irrelevant fields
• Guiding users through multi-step workflows
• Applying visual indicators like status colors and icons

Do not use display rules for:

• Hiding sensitive personal information from certain user roles
• Protecting financial or administrative data
• Any data that must remain truly private

For sensitive data, use user roles, separate tables, and source filters. See Display Rules and Data Security for the full explanation.

Next Steps

• Display Rules and Data Security. Understand why display rules aren't a security feature and what to use instead.
• Conditional Rules. Set field values automatically based on conditions at the data level.
• Source Filters. Filter which records an element displays at the source level.