Exclude Cases that have been in a certain sub state

Go to solution
leovanbelzen
Kilo Contributor

yesterday

Hi,

 

I'm building a report where I want to exclude cases that have had the sub state 'Waiting for Development' in the past. Is there an OOTB way to do this?

 

Appreciate the help!

Labels:
0 Helpfuls
  • 152 Views
1 ACCEPTED SOLUTION

Go to solution
Chris Plunkett
Giga Expert

yesterday

If there is a metric definition setup to track the state field value duration on the case table you should be able to by writing your report on the metric instance table and filtering out the particular state you'd like to omit, something like this example:

 

ChrisPlunkett_0-1768419603822.png

 

View solution in original post

2 REPLIES 2

Go to solution
Chris Plunkett
Giga Expert

yesterday

If there is a metric definition setup to track the state field value duration on the case table you should be able to by writing your report on the metric instance table and filtering out the particular state you'd like to omit, something like this example:

 

ChrisPlunkett_0-1768419603822.png

 

Go to solution
Itallo Brandão
Giga Guru

yesterday

Hi leovanbelzen,

That is a spot-on architectural alternative! You are effectively suggesting "flattening" the historical data into the main record.

Here is a quick comparison of that approach versus the OOTB Metrics method:

The "Custom Flag" Approach (Your Idea)

  • Concept: Create a field u_has_been_waiting_for_dev (True/False) and use a Business Rule to flip it to true when the state changes.

  • Pro: Best possible performance for reporting. It's much faster to query a boolean field on the main table than to join related tables.

  • Pro: User Experience. It is much easier for non-technical users to just filter Has been waiting is false.

The Challenge (Legacy Data) As you correctly identified, the tricky part is the "Fix Script" to update old records.

  • To populate this flag for existing Cases, your script would need to query the Audit/History tables.

  • Warning: Querying sys_audit or sys_history_line is performance-intensive. If you go this route, ensure you run the update script in small batches (e.g., updating 1000 records at a time) during off-hours to avoid slowing down the instance.

Summary:

  • Use Metrics (OOTB) if you want a "No-Code" solution and the report volume is low/medium.

  • Use the Custom Flag if this report will be run very frequently (e.g., on a Homepage/Dashboard) and you need maximum speed, and are willing to manage the backfill script.

If this response helps you solve the issue, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards,

Brandão.