To ensure your team speaks a unified operational language and captures identical data across work items and workflows, BusinessChat uses a centralized customization engine.
Tags, Fields, and Statuses form the core building blocks of your workspace configuration. While some elements are shared universally across all Work Items, others are restricted or customized based on the category you are using.
1. Fields
Fields dictate the structural data captured within a work item. Instead of typing unstructured notes, fields keep your data clean, searchable, and comparable.
Field Sources & Types
BusinessChat supports three distinct sources of fields:
Standard Fields: System-defined fields created by default (e.g., Title and Description). These cannot be edited or deleted by the user.
Reference Fields: Fields pulled dynamically from active data integrations (e.g., an e-commerce Order ID or Order Status retrieved via an external integration).
Manual Fields: Custom fields created directly by your business admins.
Available field formats include: text, number, date, single-select, multi-select, link, attachment, boolean (Yes/No), phone number, and email.
Availability Matrix
The system applies strict rules regarding which categories can accept additional data fields:
Field Behavior | Tasks | Tickets | Incidents |
Title & Description | Mandatory | Mandatory | Mandatory |
Accepts Custom / Reference Fields | No. Accepts no other fields. | Yes. Add as many as needed. | Yes. Add as many as needed. |
Ordering Control | Fixed. | Fully customizable per type. | Fully customizable per type. |
Per-Type Mandatory Toggles | N/A | Admins select which are required. | Admins select which are required. |
How to Create and Manage Fields
Navigate to Settings from your profile avator icon
From Fields, within Work Items Settings, Click New Field.
From the popup, add a name for your field, then from the dropdown, choose the type of the field. Finally click Save.
You can edit or delete any field, by choosing an action from the Action items next to the field name.
💡 Note on Deletion: Deleting a manually created field or deactivating a reference field acts as a soft delete. Archiving a custom field permanently unbinds it from every work item type configuration that uses it. However, values already written to open or resolved cases stay securely stored in the database and continue to display as read-only metadata on historical work items.
2. Statuses & Stages
Statuses trace the progress of an item from its creation to its eventual resolution.
The 5-Stage System Infrastructure
The system uses five fixed, immutable parent stages to calculate metrics and manage the SLA clock. Businesses cannot add new top-level stages or alter their baseline logic:
Submitted: Created but not yet claimed. Time-to-Resolve (TTR) SLA clock starts running.
In Progress: Actively being worked. SLA clock is running.
Waiting on Customer: Blocked by customer dependency. SLA clock pauses.
Resolved: Work is complete (terminal state). SLA clock stops; CSAT surveys can trigger here.
Canceled: Work called off (terminal state). SLA clock stops.
Availability Matrix
While the parent lifecycle is universal, status customization rules vary dramatically across categories:
Status Behavior | Tasks | Tickets | Incidents |
Custom Sub-Statuses | No. Uses standard, uneditable statuses. | Yes. Add, rename, or reorder sub-statuses under any stage. | Yes. Add, rename, or reorder sub-statuses under allowed stages. |
"Waiting on Customer" Stage | Present (Maps to standard Pending customer status). | Present (Used to pause active SLA clocks). | Completely Absent. Incidents do not have this stage. |
Configuration Constraints | N/A | Must configure at least one active status per parent stage. | Must configure at least one active status per allowed parent stage. |
System Lifecycle Constraints
The Global Status Pool: Statuses do not live inside individual tickets or tasks; they exist in one centralized, shared status pool per business. A work item type config simply pulls statuses from this global pool, allowing the exact same sub-status to be reused across multiple different workflows.
No Semantic Overrides: Businesses cannot alter the underlying core logic of top-level parent stages. For example, you cannot configure a sub-status sitting under the In Progress stage (such as *"Waiting on 3rd Party Vendor"*) to pause the SLA clock. The system protects lifecycle definitions to maintain accurate reporting metrics.
Team Assignment Bindings: For every active sub-status added to a Ticket or Incident workflow configuration, admins must bind a designated backend team when submiting the ticket. When a work item moves into that status for the first time, it triggers the system's automated round-robin routing logic to fairly distribute the case across active members of that specific team.
How to Create and Customize Statuses
Navigate to Settings from your profile avator icon
Under Statuses, within Work Items Settings> Statuses, Click Add Status.
From the popup, choose the Main status from the dropdown, and add a name or the new sub-status. And click Save.
To remove custom sub-statuses from your workflow, you must use the archive function. Archiving serves as the system's unique soft-delete path; there is no separate "hide" toggle. Main system parent stages are permanent and cannot be deleted or bypassed. To archive a sub-status, click the Trash icon, choose a replacement and confirm archiving.
⚠️ Safe Status Removal: If you remove an active sub-status from a specific workflow configuration, the system requires you to reassign all currently open items sitting in that sub-status to an alternate active sub-status in your workflow.
3. Tags
Tags are flexible, color-coded custom properties that allow your team to add an extra layer of organization, categorization, and filtering to their queues.
Tag Groups
To keep tags organized, they are created inside Tag Groups (for example, a tag group named "Priority" or "Issue Type").
Availability Matrix
Tags are universally available across all three categories, but feature strict execution rules to keep your queues structured:
Tag Behavior | Tasks | Tickets | Incidents |
Supported | Yes. | Yes. | Yes. |
Multiple Groups | Admins can create multiple distinct tag groups per category. | Admins can create multiple distinct tag groups per category. | Admins can create multiple distinct tag groups per category. |
Selection Limit | Strictly one tag can be selected per tag group on an item. | Strictly one tag can be selected per tag group on an item. | Strictly one tag can be selected per tag group on an item. |
⚠️ Tag Selection Engineering Constraint:
While a single work item can hold multiple tags simultaneously to give your team extreme reporting flexibility across regions or segments (e.g., a ticket tagged with both `Riyadh` and `VIP Customer`), selection is strictly single-select per tag group. Users cannot apply more than one tag from the exact same group (e.g., a ticket cannot be marked as both `High` and `Low` inside a single `Priority` group).
How to Create Tag Groups and Tags
Navigate to Settings from your profile avator icon
Under Statuses, within Work Items Settings>Tags, Click Add Group.
Name your group (e.g., Sentiment).
Inside your new group, click Add Tag, and input a Tag Name (e.g., High), click outside the box and then click on the color icon to assign a color of your choosing.
Once saved, your team can instantly select these tags via dropdown selectors on the right-hand panel of their respective Work Item entity pages.
You can delete. group tag by clicking the delete icon inside the tag box.
