The OOTB Busy Indicator is not triggered by default for case creation in self service portal

User Experience
1

We are using Peg Constellation 25.1.2

We have a self service portal where user can creates a case using ootb case launcher widget.

The case creation is taking some time as it has some API calls which we really cant avoid.

During that time user is not aware that the case is being created and clicking on the create button multiple times.

We would like to show busy indicator during that time which will avoid the above situation and appropriate.

I guess the default ootb busy indicator should be triggered in these scenarios.

But its not getting triggered.

Any idea? or suggestions ?

2

Hello @Pavan_Kumar_Koduri

I would look beyond the busy indicator itself and focus on why the case creation is taking time.

If the case is being created through the OOTB Case Launcher, the delay is likely coming from processing that occurs during case creation, such as external API calls in the initial stages of the case lifecycle as you mentioned. While a busy indicator would certainly improve the user experience, it doesn’t eliminate the underlying latency.

A few thoughts:

  • Are the external API calls truly required before the case is created, or can they be moved to a Queue Processor/background process after case creation?
  • Is the data needed immediately on the first screen, or is it only used later for business rules, routing, or visibility conditions?
  • If the data isn’t required upfront, consider creating the case immediately and enriching it asynchronously afterward.

Also, if users are clicking the button multiple times, I would verify whether the Case Launcher is disabling the submit action after the first click. Preventing duplicate submissions is just as important as having a loading indicator.

Understanding how the external data is being used will help determine whether this should be solved at the UI level (busy indicator/button disable) or through an architectural change to reduce case creation latency. In my experience, addressing the latency source usually provides a better long-term solution than relying solely on a loading indicator.

Think through the above points and come up with more information.

Regards

JC

3

I completely agree with @JayachandraSiddipeta! I understand we have to trigger the APIs to external systems for the case, however there are ways which can be done through background jobs to reduce the user impact. If we don’t fix the underlying issues as JC mentioned, then we might see alerts in the PDC. It would be good to handoff the heavy lifting jobs to QP , so the front ends responds quickly and no lag to the users.

4

Thanks @JayachandraSiddipeta @RameshSangili

I completely align with your perspective and share the same view. However, due to current constraints, that approach is not feasible at this time. Please let me know if you have any additional recommendations or insights regarding the busy indicator solution.