Advice : Question on Technical Debt

[Ram117]

Hello Friends,

I'm looking for some architectural guidance on a requirement regarding Future Approvals and how to balance business value against platform maintainability.

We have a Legal contract request process driven by Flow Designer. Because we support multiple contract types, we use several different flows—each with its own distinct, sequential approval steps.

Business Req : Our fulfillment teams (primarily supporting the Sales team) need visibility into the upcoming/future approval steps for a running request. This allows them to proactively chase down subsequent approvers and expedite contract completion.

Challenge & my approach : 

Since Flow Designer executes sequential approvals dynamically, there isn't a native, out-of-the-box (OOB) way to display "yet-to-be-triggered" approvals in the Service Portal or on the classic standard form.

To solve this, I am considering building a de-coupled, on-demand calculation engine (e.g., via a Script Include) that parses the active flow/contract type, determines the remaining approval path, and renders it in a custom UI component without storing the data.

Value vs Tech Debt

There is a business value in doing this, but at the same time its a technical debt in-terms of redundant code , additional maintainability of this code.

1. Has anyone successfully solved the "future/pending approvals" visibility gap in Flow Designer?
2. Can you guys give some thoughts / inputs on what angle I should be looking at this ?
3. How have you balanced the trade-off of custom-built visualization vs. platform maintainability in similar scenarios?

I would love to hear your thoughts and experiences.

Thanks in advance!