Design philosophy for a custom app with the ability to revert to previous stages and loop

[Corsair831]

Hello,

I have an ask for a custom app which progresses linearly through stages in a top-level record, with multiple second-level related records in several of the stages, with those themselves having third-level "tasks". Sort of a hybrid between the OOTB REQ/RITM/SCTASK model and the Change model.

This in itself is quite simple however it is complicated by also needing to have the ability to (at multiple points) go back to previously completed steps and add to them, and then to linearly begin to progress to the next stage as before; AKA a loop. Some of these loops have loops within them themselves.

My thought was to use hidden UI Actions controlled by a Client Script, where each UI Action is hidden and revealed depending on the top level record's stage. These would progress the top-level record to the next read-only stage, as is done in a Change Request, with the loop initiated by a UI Action allowing you to revert to a previous stage and simultaneously create a new second-level related record. When a second level record is needed, when this is completed it progresses the top level record to the next linear stage (as is the case with SCTASK/RITM stages). I would use stage-triggered flows for specific areas where approvals etc are required. I would also be using Workspaces.

Originally I looked into the idea of using a single master flow with multiple subflows however there is currently no ability to revert to a previous step in a flow, meaning that I'm not sure how I'd complete this in my loop (especially considering this requires loops within loops).

My question is - does anyone see any issues with this design, and does anyone think there might be a better way to do this?

I realise this is quite an in depth question so many thanks for all and any answers.

[Mark Manders]

Have you checked on the usage of playbooks?

[Corsair831]

Hi Mark,

I have not; I don't suppose you'd mind giving me a couple of pointers on the advantages of using a playbook here over using UI Actions combined with a read-only stage field at all?

Many thanks

[Mark Manders]

For one, you can add the stages in the playbook as just that: stages. You can also easily go back if needed. You can use your (sub)flows withing the playbook and based on the outcome do whatever is needed and since you are using Workspaces: they are embedded in there. 

You are simply guiding your users through what they need to do.