Skip to main content

Overview

Constraints enforce data integrity rules on items. They control what values are allowed in fields based on conditions — think of them as “if this, then only that” rules for your data. Constraints are more powerful than simple cascading dropdowns because they work across any combination of list and picker fields. They ensure that your team can only enter valid data combinations, reducing errors and keeping your work items consistent.

Creating a constraint

Each constraint is built from a trigger (the “if” condition) and a constrained field (the “then” restriction). You configure these under Settings > Constraint.
PropertyDescription
NameA descriptive name for the constraint
ContainerWhich containers the constraint applies to (select All for tenant-wide)
Trigger fieldThe field that triggers the constraint — when this field changes, the constraint is evaluated
Trigger valueThe specific value of the trigger field that activates the constraint
Constrained fieldThe field whose available values are restricted by the trigger
Constrained valueThe values that are allowed or blocked in the constrained field
At the bottom of the form, two toggles control the constraint mode:
  • Only selected values allowed — include mode: the constrained field can only contain the selected values
  • All values allowed except selected — exclude mode: the constrained field can contain any value except the selected ones
These toggles are mutually exclusive — enabling one disables the other.

Include and exclude logic

Include constraints

An include constraint says: “if the trigger field has this value, then the constrained field can only have these specific values.” You specify exactly which values are allowed. Any value not in the list is blocked. Example: If Priority is High, then Status can only be In Progress, On Hold, or Closed.

Exclude constraints

An exclude constraint says: “if the trigger field has this value, then the constrained field can have any value except these.” You specify which values are blocked, and everything else remains available. Example: If Status is Closed, then Resolution cannot be Unresolved.
Use include when the allowed set is small and well-defined. Use exclude when you only need to block a few specific values.

Where constraints apply

Constraints are scoped to containers. When you create a constraint, you select which containers it applies to — or choose All to apply it across every container in the tenant. Constraints apply to both list fields (like Status or Priority) and picker fields (like Cost Center or Job Role). This means you can control not just dropdown selections but also entity lookups.

Constraints vs. process configuration

Constraints are one of three mechanisms on a process that control item data. Each serves a different purpose:
MechanismWhat it controlsConfigured on
ConstraintsWhich field values are allowed based on conditionsSettings > Constraint
WorkflowWhich status transitions are allowed, and who can make themProcess > Workflow tab
Field configurationWhich fields appear on items, and who can view or edit themProcess > Field tab
If you need to restrict the values a user can select, create a constraint. If you need to control which statuses an item can move to, configure the workflow. If you need to show or hide a field entirely, use the process Field tab.

Rules bypass constraints

Rules can set field values that would otherwise violate a constraint. This is by design. Rules act as a data manipulation escape hatch, allowing automated processes to make changes that user-driven actions cannot. For example, a rule might automatically set a status that a user could not select manually due to a constraint. This separation means constraints protect against user error while rules handle automated workflows without being blocked.