Status Conditions
Feature ID: FU-10126
Document Version: 1.0
Date: 24-10-2025
1. Introduction
Every process in Unifize has one or more records. In each record’s chatroom header, the Status tab shows the current stage of the record and lets users move the work forward accordingly. The behaviour of the status tab can be controlled by the admins based on certain Status Conditions. With conditions you can show, hide or disable a status until certain qualifiers are met.
This allows admins to configure when and under what conditions should their status field be visible.
2. Feature functionalities
You can choose a base state per status. This means you can hide, enable or disable your status tab until certain qualifiers set by you are met.
You can create conditions based on the existing checklist fields of the process or based on the other fields of the chatroom such as owner, due date, status, and user.
You can use a list qualifiers based on your selected condition. Only after this set qualifier is met, will the condition be fulfilled.
Easily combine multiple conditions using the “+ Add condition (AND)” to require more than one prerequisite before the behavior takes effect.
You can set the behavior that should apply when your condition has met the qualifier and your condition comes true.
3. Admin journey
This is is how you can configure the Status conditions:
A. Open the Status conditions
Go to Manage view → open a process.
Open Status.
For the status you want to control, click the settings (gear icon) → Conditions.
B. Pick a base state
You can choose from a set of base states that the status field will adhere to until your condition meets the required qualifier.
Hide until condition met – the status tab stays hidden until the qualifier is met
Enable until condition met – the status tab stays enabled until the qualifier is met
Disable until condition met – the status tab stays visible but disabled until the qualifier is met. You can also add a short tooltip text if your based condition is disable (“Fill due date to enable”) so users know what to do to enable that particular status field.
C. Add the rule (Condition → Qualifier → Behavior)
Choose the Condition (what to check)
Select the condition for this status option. This tells the system which field to evaluate for this rule. It can be based on either:
a checklist field from the same process (e.g., Text, File upload, etc) or
an other chatroom field on the record: Owner, Due date, Status, or User (Current user).
Note: It's important to note that Status Conditions don't work on AI, Revision, Sections, Subsection and PDF Checklist fields.
Choose the Qualifier (how to evaluate it)
Pick the qualifier that matches the selected field so the rule knows what to look for. You can pick from a set of different qualifiers for different condition.
All Checklist fields (other than exceptions below)
is filled, is empty
Picklist / Linked Record / Owner
is any of, is none of, is filled, is empty
Number
is greater than, is less than, is equal to, is filled, is empty
Status
is any of, is none of
Approval
is approved, is empty
Due date
is empty, is filled, is overdue
User (Current user)
is any of, is of role, is not of role, is creator, is owner, is part of
Choose the Behavior
Select the Behavior to apply when the condition meets the qualifier (i.e., the rule evaluates to true):
Show (make visible and enabled),
Hide (hide from the menu), or
Disable (keep visible but not selectable; add a brief tooltip text explaining why it’s locked).
The Behavior will execute according to the base state you selected earlier (Hide until / Enable until / Disable until).
(Optional) Add more conditions
Use + Add condition (AND) to require multiple checks at once (e.g., Due date is filled AND User (Current user) is owner). Keep combinations minimal and clear.
OR conditions (separate blocks)
You can also combine different OR conditions for your status:
Click "+ Add New Condition" to create a new block; each block is evaluated as an OR condition against the previous block of condition.
Inside a block, any checks you add with "+ Add condition (AND)" must all be true for that block to pass.
Evaluation order is: apply the base state → evaluate Block 1; if Block 1 is true, the rule is met and evaluation stops; if Block 1 is false, evaluate Block 2; continue the same way for additional blocks.
If any block evaluates to true, the configured Behavior is applied. if none are true, the status remains in the base state.
Example: make “QA approved” available when (Due date is filled AND Owner is filled) OR (Approval is approved).
Save Changes
Save to apply the rule to this specific status option. Other options are unaffected.
D. Logical pairings (keep behaviors sensible)
To make sure, your conditions are correctly configured and are logical, you can use the below guide as a reference.
Hide until condition met
Configured status is hidden.
You can either: a. Show Status (make it visible) b. Disable/Lock Status (visible but not selectable).
Status remains hidden.
Hide Status (same as base state→ redundant and logically will not cause any change in behaviour).
Enable until condition met
Configured status is visible & enabled.
You can either: a. Hide Status (remove from view) b. Disable/Lock Status (keep visible but not selectable).
Status stays visible & enabled.
Show Status (same as base state→ redundant and logically will not cause any change in behaviour).
Disable until condition met
Configured status is visible but disabled/locked
You can either: a. Show Status (enable/selectable) b. Hide Status (remove from view).
Status stays disabled/locked
Disable/Lock Status same as base state→ redundant and logically will not cause any change in behaviour).
4. User journey
Status appears in the record/chatroom header. What shows up in the Status menu—and whether an option can be clicked—depends on conditions you configured for your process.
Each condition checks a condition, evaluates it with a qualifier, and then applies a behavior. This configuration will be experienced by the org members as it is.
When an org member open the record and click on the Status tab in the chatroom header. They’ll see only the options that are allowed for them at that moment; others may be hidden or shown but disabled based on the set condition.
If an option is disabled, they can hover over it to see the tooltip text explaining what’s required (for example, set Owner or fill Due date).
When an option is available and the org member select it, they will get a comment box to add context. They can either add a comment for their staus or skip it as this is optional.
4.1 How conditions appear to end users
Hide until condition met
The option is not visible.
The option appears according to the configured behavior (typically Show Status, or Disable/Lock Status if it should remain visible but locked).
Disable until condition met
The option is visible but disabled (tooltip text explains what’s missing).
The option becomes enabled (or hidden if that is the configured behavior).
Enable until condition met
The option is visible and enabled.
The option becomes disabled or hidden as configured.
5. Best practices
Prefer “Disable until condition met” + tooltip text over hiding the field when you want users to learn what’s missing. Hide only when the step should be invisible until ready.
Gate sensitive steps by role (e.g., Current user is owner/creator) to reduce noise and prevent accidental status change.
Use AND sparingly - two or three conditions are easier to understand and maintain than complex chains.
Test as a non-admin to confirm tooltips, disabled states, and visibility behave as intended.
Keep pairings logical using the table above; avoid behaviors that mirror the base state.
Last updated