Case History write conflict - How to mimic a 1 second wait?

General
1

Case History write conflict - How to mimic a 1 second wait?

Hi all, are there any ways to mimic a 1 second wait (doesn’t have to be exact) in a flow?

The Wait shape in a flow can be configured to be 1 second but ends up taking 12-15 seconds due to how it’s processed. It does solve my problem, but I want it to be 1 second so users don’t have a noticeable wait.

The issue I’ve run into is that if I’m writing a lot of data to the case history, the system doesn’t wait for those writes to complete before moving on, and in some cases, if the start of the next stage wants to write to the case history, it will write to the history in the middle of the other writes. And you get something like the below that looks out of order and can even stop some writes from happening. Adding a wait allows the writes to finish in order as configured.

Example of NO issue - Case History (Newest to Oldest):

  • 12.30pm - Assigned to ABC Queue to “complete task”
  • 12.30pm - Status changed to Open-Triage
  • 12.30pm - Case moved from Collect to Triage via automatic transition
  • 12.30pm - PropertyF updated to ‘F’
  • 12.30pm - PropertyE updated to ‘E’
  • 12.30pm - PropertyD updated to ‘D’
  • 12.30pm - PropertyC updated to ‘C’
  • 12.30pm - PropertyB updated to ‘B’
  • 12.30pm - PropertyA updated to ‘A’

Example of issue - Case History (Newest to Oldest):

  • 12.30pm - Status changed to Open-Triage
  • 12.30pm - Case moved from Collect to Triage via automatic transition
  • 12.30pm - PropertyF updated to ‘F’
  • 12.30pm - PropertyE updated to ‘E’
  • 12.30pm - Assigned to ABC Queue to “complete task”
  • 12.30pm - PropertyC updated to ‘C’
  • 12.30pm - PropertyB updated to ‘B’
  • 12.30pm - PropertyA updated to ‘A’

So you can see for some reason the Queue assignment wrote to the history out of order and it stopped the PropertyD write from occurring altogether.

NOTE: I grant that this is not efficient code and I’m looking at fixing it, but wanting a band-aid in the short-term so history isn’t lost.

2

What you’re seeing is a known side effect of how Pega processes history writes asynchronously. The problem isn’t really that the flow is “too fast”—it’s that history records (History-Work) are not guaranteed to be committed or written in the exact order that the flow executes.

A 1-second sleep is unfortunately not something Pega exposes in flows.

Why the Wait shape doesn’t work well - The Wait shape is designed for case suspension and resumption, not for introducing a short delay. Even if configured for 1 second:

the case is persisted,
a queue item is created,
an agent/job scheduler resumes the case,
the resume depends on polling intervals and queue processing.

This is why you typically see 10-15 seconds instead of 1 second.

Possible short-term workarounds

  1. Commit before moving stages (best short-term option)

If your property updates are happening in an activity, explicitly committing before the stage transition can help.

For example:

Property updates->Obj-Save (history/work)->Commit->Advance to next stage

This forces the current transaction (including history records) to complete before the next assignment generates more history. Obviously only do this if introducing an additional commit is acceptable in your application.

  1. Use a Queue Processor (recommended architecturally)

Instead of writing lots of history synchronously:

Update properties->Queue Processor->Advance stage

or

Advance stage->Queue Processor performs history updates

This gives you deterministic ordering because all history updates happen in one processing context.

  1. Reduce the number of history writes

Looking at your example:

PropertyA updated
PropertyB updated
PropertyC updated
…
PropertyF updated

that’s six separate history entries.

Instead, consider:

Properties updated:
A
B
C
D
E
F

or even one custom history message. This avoids the race almost entirely.

3

Thanks Ajay! We solved the issue by doing your 3rd option - Created a temp page list with all the changes made in the current flow, and then do a single post-process history write.