Advice : Question on Technical Debt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
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.
- Has anyone successfully solved the "future/pending approvals" visibility gap in Flow Designer?
- Can you guys give some thoughts / inputs on what angle I should be looking at this ?
- 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!
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
56m ago
@Ram117 Two cents from my side on customisations, there will always be some requirements which can't be implemented via OOTB features. Sometimes it is necessary to do customisations to fulfil business objectives. There is no harm in implementing a custom solution which doesn't change the OOTB ServiceNow artefacts (BR, Script Include etc.), you need to make sure that the solution you are designing is scalable and aligns with the platform best practices.