Status
1. Introduction
The Status feature in Unifize is designed to help teams track the stage or progress of each record within a process. Every process in Unifize can have multiple records, and within each record, the chatroom header displays a status indicator. This is what end-users see when interacting with the record, making statuses a key way of communicating progress or completion of work.
By default, every process comes with three primary statuses:
Pending
Completed
Cancelled
Note: Admins can reorder, create sub-statuses, map sub-statuses to a default type, configure archiving behavior, and apply conditions that hide/disable/enable statuses.
2. Feature functionalities
Default status and sub-statuses: You can use the three existing default statuses - Pending, Completed, and Cancelled or create custom statuses mapped to either of the two default statuses that is Pending and Completed.
Reorder options: You can drag or delete statuses to control the order shown in the chatroom dropdown or delete a particular status, respectively.
Configure archiving behaviour: You can control the archiving behaviour when your custom status is selected by choosing from options such as Auto archive or Auto unarchive so selecting that status changes archive state as intended.
Configure status conditions: You can configure the behaviour of your status via conditions and therefore Hide, Enable, or Disable your status until your required conditions are met.
Enforce safe deletion: The system will prevent deletion of existing default statuses if any record of the process currently uses that status or if the default status doesn’t have any sub status mapped to it.
Audit traceability: Every status change is automatically logged in the chatroom activity for traceability, so keeping track of the status history is easy.
3. Admin journey
This section talks about how you can configure the Status feature as an Admin.
A. Where to configure
Go to the Manage View section
Open the process for which you want to configure the status for
Go to the Status tab
3.1 Default statuses
Every process has two default statuses: Pending and Completed. Any record is either in progress (Pending) or finished (Completed)—these two cover the common lifecycle.
What users see: Pending and Completed appear in the Status menu in the record header (along with any custom statuses you add). Users will also be able to see the Cancelled status, which will basically allow them to close the record. However, no specific configuration is available for the Cancelled status.
What admins can do here:
Reorder the list by dragging the status to modify the order in which the users see the statuses.
Delete a default status only if both checks pass:
The process still has at least one status mapped to Pending and at least one mapped to Completed (i.e., you created your own replacements).
If not, you’ll see: “You need to have at least one status mapped to PENDING and COMPLETED each.”
b. No record currently uses the status you’re deleting. If it’s in use, you’ll see an error message highlighting Cannot remove status PENDING and the reason why it cannot be removed. You can use the link shown (e.g., View 10 conversations marked as “PENDING”) to view all the records first using the status.
3.2 Create a configurable status
A configurable status is a sub-status you create under one of the existing default statuses - Pending or Completed. Every custom status needs to clearly belong to either the in-progress (Pending) side or the done (Completed) side.
This can be done by:
Click “+ Create new status” and give it a clear name (e.g., “Owner assigned”, “QA verified”).
Open Status Settings:
Status Type: You have to map your new status to one of the existing status types by clicking on either of the one - Map to Pending or Map to Complete. This decides which of the default statuses type the new status belongs to.
You can select the Archive behavior that you want the process to adopt once your custom status is selected:
Ignore archiving - selecting the status does nothing to archive state.
Auto archive - record archives the moment this status is set.
Auto unarchive - if the record if archived, record unarchives when this status is set.
Set Conditions
Next, you can control the behaviour of your status field by configuring specific conditions.
You can control how and under what conditions a status option appears to end user. A condition is a rule that looks at various fields of the record and then applies a behavior (show, hide, or disable) to that status option.
3.1 How conditions work
Each status you configure starts with one base condition - this sets the overall intent:
Hide until condition met: keep the status hidden until the condition becomes true
Enable until condition met: keep the status enabled until the rule becomes true
Disable until condition met: keep the status disabled until the rule becomes true
3.2 What a condition can reference
A condition can be based on either of these sources:
Other checklist fields in the same process. Any existing checklist field other than AI checklist field, revision, Generate PDF.
Built-in context for the status: Existing fields for that record other the checklist fields. Owner, Due date, Status, User (Current user).
You can combine multiple conditions with AND (e.g., Owner is filled AND Current user is Owner).
3.3 Qualifiers
When you pick a field or context, choose a qualifier to define the rule, for example:
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
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
3.4 Default behaviors
After the base condition and condition qualifier, you can set a Behavior. This is behaviour the field will fall to if the condition is met. If the condition is not met, the field will remain in the base condition. There are three types of behaviour you can choose for:
Show – the status is visible
Hide – the status is not shown in the list.
Disable – the status is visible but not clickable. *(*For this, you can add a helpful Tooltip so users know why it’s disabled.)
Keep it logical: Don’t pair a base mode with a behavior that cancels its purpose. Use the logical pairings table below.
3.5 Logical pairings
Base condition
Before rule is true
Recommended Behavior
Avoid (illogical)
Hide until condition met
Status is hidden
Show Status OR Disable/Lock Status
Hide Status (stays hidden),
Enable until condition met
Status is visible & enabled
Disable/Lock Status OR Hide Status
Show Status (no effect)
Disable until condition met
Status is visible but disabled
Show status, Hide status
Disable/Lock Status
Save Changes, then drag to reorder if needed.
Notes
You can use the tooltip only with Disable until condition met to explain why an item is disabled (e.g., “Fill due date to enable”).
Combine checks with AND for simple gating (e.g., Due date is filled AND Attachment is filled).
When in doubt, pair each base mode with the “Sensible Behavior” shown above to avoid contradictory outcomes.
4. User journey
This section will help you understand how end users see status feature and how it behaves for them:
What end users see in the status menu
There are three broad categories of statuses in a record’s chatroom header:
Pending – work in progress
Completed – work finished
Cancelled – record no longer needed
You may also see sub-statuses inside Pending and Completed (e.g., “Owner assigned”, “QA verified”).
Visibility and names depend on how your org has set things up. Admins can add or remove options.
Colors help users recognize the category:
Anything mapped to Pending uses the same grey style as Pending.
Anything mapped to Completed uses the same style/color as Completed.
Cancelled has a dark grey color to it.
4.1 Changing a status
Users can change the status type by:
Clicking on the Status tab in the chatroom header.
Picking the option that matches their required status stage (e.g., a Pending sub-status during work; a Completed sub-status when done).
Any status change done by end users is logged in the record’s audit trail (who changed it and when).
4.2 Some options may be hidden or disabled
Based on the admin configuration, some options may appear as hidden or disabled for the end users. This is because:
Some statuses appear only when prerequisites conditions set by the admin are met (e.g., due date filled, owner set).
Some options may be visible but disabled until the user complete a requirement set by the admin. If added by the admin, they can understand the context of why the status is diabled by hovering over the status to see the tooltip text (e.g., “Fill due date to enable”).
4.3 Archiving behavior
At the end of the status tab, users will see an “Archive this conversation” in the status menu. They can use that option to archive that particular record. They can still access that record by going to “All Records” → “Archived” option.
They can select certain statuses that will auto-archive the record (commonly when they choose a Completed status type).
Selecting other statuses may auto-unarchive (bringing an archived record back to active).
4.4 Status use case for end users
Users can track progress clearly with Pending, Completed, Cancelled (and their sub-statuses).
Use tooltip texts in disabled statuses as checklists for what’s required next.
Close or reopen work via archive/unarchive when available.
Users can track the status history of your record by relying on the audit trail. Every status change is recorded for transparency.
5. Important things to remember
Keep at least one status mapped to Pending and one to Completed if you wish to delete a default status; you can’t delete a default if any record still uses it.
Sub-statuses inherit the color of what they’re mapped to (Pending = grey; Completed = green).
Archiving and conditions setting is per status, and not for any other statuses.
Conditions control visibility and behaviour of your status. Pick one base mode and pair it with a logical behavior.
What and how users see your status depends on your configuration: items can be hidden or disabled until requirements (e.g., Due date, Owner) are met.
6. Roles and Permissions
Admin
Configure statuses, add new statuses, delete existing default statuses, set behaviours and conditions to statuses, control other users access to statuses
Org member
Change status on records they can access; archive the conversation, trigger archive/unarchive when the chosen status allows
External user
Usually view-only; visibility and actions depend on admin configuration.
7. Best practices
Use the existing default statuses as the baseline for the custom statuses you want to create. Your record should be in either pending, completed, or cancelled state, any configured sub status can be inside these broader status categories.
Name and define your statuses clearly. Keep it in correct sequence so it’s easier for end users to understand the status type. Order statuses for the real workflow - progressive Pending steps first, Completed options last.
Gate “Completed” statuses with minimal must-have fields using Disable until + tooltip text, which is a better practice than simply hiding the status.
Last updated