Use case status history with automation
Overview
Tracking the lifecycle of a use case often requires storing the history of status changes.
This documentation describes how to automatically generate a status history whenever a Use Case status is updated.
The mechanism relies on:
An automation triggered by status updates
A dedicated concept storing history records
Optional duration computation to measure time spent in each status
Although the example applies to use cases, the same automation pattern can be reused for many other concepts or other needs.
History Use Case
A dedicated concept must be created to store history records : the History Use Case concept records every status change of a Use Case. It must be then embedded in the Use Case concept.
Recommended Fields
History Use Case
Field | Type | Description |
|---|---|---|
Updated by | Association (N-1 → User) | User responsible for the update |
To | Association (N-1 → Status) | Status reached after the update |
On | Date | Date when the status change occurred |
Duration | Number (optional) | Time spent in the status |
Duration is optional.
It is only required when measuring how long a Use Case remained in a given status.
Use Case
Field | Type | Description |
|---|---|---|
History Use Case | Embedding (with History Use Case) | Embedding field storing history records |
Last history Use Case | Association (N-1 → History Use Case) | Used to compute the duration by knowing the last history record for which the duration needs to be computed |
New history Use Case | Association (N-1 → History Use Case) | Used to compute the duration by knowing the new history record created |
Last history Use Case and New history Use Case are optional.
It is only required when measuring how long a Use Case remained in a given status.
Automation Trigger
The automation must execute when the Status field of a Use Case changes.
Trigger Configuration
This ensures the automation runs every time the status changes.
Automation updates
The automation performs several operations:
Store the previous history record : before creating a new history entry, the previous history record must be stored. This allows the system to later compute the duration spent in the previous status.
Create a new history entry:
Record the responsible user
Record the date of the change
Record the status reached after the update
Optionally compute the duration spent in the previous status
Handling Integration or System updates
Some status updates may come from:
Integrations
Automations
Migration / System
In those cases, the Triggering user is empty, and it is possible to represent those update via a dedicated system user that can be created.
Using Self Filters to Handle Two User Scenarios
The automation must handle two possible situations when a status update occurs:
The update is performed by a platform user
The update is performed by an integration or the system
The challenge comes from the fact that the Only if condition of an automation block only allows one global condition.
However, the automation requires two different behaviors depending on whether the Triggering user is empty or not.
To solve this limitation, two Create blocks are used, each relying on a Self field that can be used for filtering (more can be found about this tip on the documentation).
This technique allows the automation to simulate conditional branching.
Compute duration
When duration tracking is required, a computed field must be configured.
Important: Automation block order
The order of automation blocks is critical when computing durations.
Correct sequence:
Update the previous history record
Create the new history entry
Compute the duration
The duration calculation requires the new history entry to exist before execution.
Incorrect ordering will produce incorrect duration values.
Known Limitations
Duration values depend on the chronological integrity of history records.
Manual modifications may introduce inconsistencies.
Examples:
Modifying the On date
Deleting a history record
Inserting history entries manually
These actions may produce incorrect duration calculations.
If inconsistencies occur, duration values must be manually corrected. All other automation behavior remains unaffected.