Return to Previous Step when in same stage - prod application

General
1

I’m looking for recommendations/best practices for implementing a “Return to Previous Step” functionality in a production-grade Pega application.

Scenario:

  • A case is currently within the same stage.

  • Example flow:
    Assignment1 → Assignment2 → Assignment3

  • User is currently at Assignment3 and wants the ability to go back to Assignment1 or Assignment2.

  • it is not screen flow and we dont have any go back button.

  • Application is live and have existing production cases.

I am thinking to use restart stage as first option.
My concern with loopback connectors is that they may become difficult to maintain in large production workflows.

How have others implemented this requirement in real-world production applications? What approach would you recommend as the most stable and maintainable architecture?

2

As an alternative to restarting the stage, you can use SetTicket to navigate the user back to a previous assignment, especially since this is not a screen flow and the application is already live in production.

3

Hi @Debanjan_Seth : I would still recommend to use loop back connectors in this case. I assume you wouldn’t have too many assignments within the same stage.

If you have too many combinations, you can also design to have just one go back flow action from all the Assignments which is pointed to a decision and route accordingly.

I feel other customizations will have more cost of maintenance compared to this.

Thanks.

4

Have you considered Configuring navigation to a previous Step? I think Infinity '23 introduced the ability to turn any process into a back/fourth like a screenflow via simple configuration.

  • It will not allow you to skip from step 3 to step 1 though (that would be two “previous” clicks for user

Are you on Constellation or UI Kit? Important question as Constellation as we have some open source DX Components that might help make this a better UX.

Maintenance

Yes, irrespective of your UI Architecture, maintenance is a concern. In every variation of this I’ve seen implemented the story is always the same:

  • Early implementation: We use a single process, connectors to loop, skip etc. based on user input. You can do it, its easy for first few versions, until you get more requirements.
  • Matured implementation: This evolves into leveraging change stage, to move between the milestones (your step 1, step 2) as you can natively use change stage easily. Easier to maintain, change and keep logic isolated.