Feature ID: FU-10117

Document Version: 2.0

Date: 24-11-2025

Introduction

Every record has a Conversation window, and each Conversation has a set of Conversation Notifications, which are updates on all activity within that record. Conversation Notifications are triggered by events such as Checklist field edit, metadata changes, workflow actions, etc and are delivered in real time.

Each entry is timestamped and author-attributed to maintain a reliable audit trail, which by default is collapsed and are grouped by a sticky date separator.

Feature functionalities

• Conversation notifications capture all key activity happening within a record: checklist field updates, metadata changes (status, owner/assignee, participants, dates, priority), and conversation events (messages, Conversation created, revision created).

• Each notification shows the author and is timestamped. Value changes display old → new (deletes are struck through).

• Audit-trail notifications are collapsed by default to reduce noise and can be expanded whenever needed.

• Approvals are always expanded and show status, approver, ID, and comment.

• Messages never collapse and appear inline between notifications.

• Updates are grouped by date with a sticky separator while that date’s updates are in view.

• Use the date separator’s control to expand/collapse all audit-trail rows for the current Conversation. The same action is available from More → Expand notifications.

• Expanding/collapsing changes only your view; it does not affect other users.

• Use More → Filter → Conversations to show/hide Messages, Checklist updates, Metadata updates, Deleted, and Hidden entries.

• UI is black-and-white, tabular, optimized for quick scanning.

Conversation notifications show up by default for everyone added in the record. Admin control is limited in this feature: you can configure field-level Prompts and Automated Reminders that show as Conversation notification. Everything else (view, expand/collapse, filters) is user-level.

a. Prompts

Prompts are rules that can be configured to show a small, system-posted prompt inside the Conversation, asking specific users to complete a specific checklist field. It appears at the moment you choose (e.g., whenever they open the conversation).

• How to access it:

  • Open a checklist field → Settings → Prompts → Create new rule.

  • Configure Prompt whom: search and select Participant, Creator, Owner (or specific people).

b. Automated reminders

Automated reminders are basically scheduled reminders that show up as a notification in the Conversation after a time gap you define. It can be used to keep work moving when there’s inactivity or a due date is near or past.

• How to access it:

  • Process settings → Reminders → Add auto reminder.

  • Configure: number of days + anchor (of inactivity, of inactivity from due date, of inactivity from last reminder, from due date, from created date) and an optional message.

c. Filters

Filters are per-viewer controls that any Conversation participants can use to show/hide notification categories. You can access it by:

• Go to More → Filter → You will see 2 categories there:

  • User → Inside user, you can select “All” users or select specific users

  • Conversations → Messages, Checklist updates, Metadata updates, Deleted, Hidden.

• Audit-trail rows are collapsed by default; Approvals are always expanded.

• Messages are never collapsed.

• Date separators are sticky while in view; users can expand/collapse all from More → Expand notifications or via the separator.

This is how end users interact with Conversation Notifications.

• When your users open a record, they see the Conversation with regular messages plus audit-trail notifications (checklist updates and metadata changes) grouped by date.

• Messages are always open. Approval cards are always expanded (status, approver, ID, signature, and optional comment). All other audit entries arrive collapsed.

• Users can expand/collapse all audit rows in that Conversation by clicking the date separator or going to More → Expand notifications. While a section is in view, the separator stays sticky, and date chips fade as they scroll past.

• Start with expanded items. Read messages and approval cards first, then expand audit rows when deeper context is needed.

• Use Filter to focus reviews (e.g., hide Messages to scan Checklist/Metadata only, or filter by a specific user).

• Rely on the visual cues for viewing previous and current updates. Older data are struck through with the new data beside it.

1. Approvals cannot be collapsed: Approval and rejection notifications are intentionally non-collapsible to preserve audit visibility.

2. Global audit trail expansion: Audit trail expansion is global for the chatroom and cannot be applied on a per-date or per-notification basis.

🖋️

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.

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.

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.

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.

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

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.

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

This section talks about how you can configure the Status feature as an Admin.

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

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:

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.

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.

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:

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

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.

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

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

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

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

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

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

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