Best approach to cancel existing child case SLAs when parent case changes or a new child case is created

General
1

Hi Everyone,

I’m currently working on a Pega SIAA application and would appreciate some guidance on the best technical approach for the following scenario.

Scenario

  • An Orchestration (ORCH) case acts as the parent case.
  • A single ORCH case can have multiple Resolution Activity (RA) child cases.
  • When an RA case is created, the system automatically starts an SLA with:
    • Reminder 1 after 10 business days
    • Reminder 2 after 20 business days

Requirement

If either of the following occurs:

  1. The Orchestration (ORCH) case status changes, or
  2. The user creates another Resolution Activity (RA) case,

then the reminders (Reminder 1 and Reminder 2) associated with the previous RA case should be cancelled so they are not triggered.

My Thoughts

I have been looking into Ticket rules and was wondering whether they could be used to achieve this, but I’m not sure if that is the best approach or how it should be implemented.

Questions

  • What is the recommended way in Pega to cancel or stop an existing SLA for a child case?
  • Would Ticket rules be appropriate for this scenario, or is there a better design pattern?
  • Is it better to use an activity, queue processor, or another mechanism to remove or cancel the SLA assignments?
  • Has anyone implemented a similar requirement in Pega or SIAA and can share their approach or best practices?

Any suggestions or implementation ideas would be greatly appreciated.

Thank you!

2

Rather than cancelling the SLA, consider adding a validation check within the SLA escalation activity. Before sending Reminder 1 or Reminder 2, verify that the RA case is still the current/active RA for the parent ORCH case. If a newer RA exists or the ORCH status has changed, simply exit the activity without sending the reminder. This approach is simpler, avoids manipulating SLA queue entries, and keeps the business logic centralized and easier to maintain.

3

@RameshSangili Thanks for the suggestion. This approach is technically feasible, and I’ve resolved the issue by implementing this validation in the SLA escalation activity. It keeps the logic simple and centralized.