# 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. {% @arcade/embed flowId="rOs73msAcpIyJwa4ZZNa" url="" %} #### A. Where to configure 1. Go to the **Manage View** section 2. Open the process for which you want to configure the status for 3. 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: 1. 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: 1. Click “**+ Create new status”** and give it a clear name (e.g., “Owner assigned”, “QA verified”). 2. 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. 3. **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: | Field type | Qualifiers you’ll see | | -------------------------------------------------- | ----------------------------------------------------------------------- | | 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 | 1. 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: 1. **What end users see in the status menu** There are three broad categories of statuses in a record’s chatroom header: 1. **Pending** – work in progress 2. **Completed** – work finished 3. **Cancelled** – record no longer needed 4. 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. 5. 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: 1. Clicking on the Status tab in the chatroom header. 2. Picking the option that matches their required status stage (e.g., a Pending sub-status during work; a Completed sub-status when done). 3. 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 | Role (user role) | 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.unifize.com/admin-guide/my-inbox/record-header/status.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.