All pages
Powered by GitBook
1 of 1

Loading...

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.


This is is how you can configure the Status conditions:

  1. Go to Manage view → open a process.

  2. Open Status.

  3. For the status you want to control, click the settings (gear icon) → Conditions.

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.

  1. 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.

  1. 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.

Field type
Qualifiers you’ll see
  1. 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).

  1. (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.

  1. 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.

  1. Save Changes

Save to apply the rule to this specific status option. Other options are unaffected.

To make sure, your conditions are correctly configured and are logical, you can use the below guide as a reference.

Base state
Before condition is met
When condition is met
If condition is not met
Avoid

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.

  1. 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.

  2. 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).

  3. 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.

Base condition
Before the rule is met (condition + qualifier)
When the rule is met (behavior applies)

  • 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.

  • Example: make “QA approved” available when (Due date is filled AND Owner is filled) OR (Approval is approved).

  • Keep pairings logical using the table above; avoid behaviors that mirror the base state.

    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

    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 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

    3. Admin journey

    A. Open the Status conditions

    B. Pick a base state

    C. Add the rule (Condition → Qualifier → Behavior)

    D. Logical pairings (keep behaviors sensible)

    4. User journey

    4.1 How conditions appear to end users

    5. Best practices

    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

    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).

    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.

    spinner