Advice : Question on Technical Debt

Ram117
Kilo Sage

3 weeks ago

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!

Labels:
0 Helpfuls
  • 426 Views
2 REPLIES 2

Sandeep Rajput
Tera Patron

3 weeks 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.

Mehdi ATTAR1
Tera Contributor

3 weeks ago

Hi !

Balancing the business need for visibility against the technical debt of custom development can become quite a challenge.

To address your proposed approach directly: I wouldn’t advise building a custom engine to parse active Flow Designer definitions.
Flow Designer's underlying data model (sys_hub_flow, sys_hub_action_instance, etc.) is complex, subject to change during platform upgrades, and extremely difficult to parse accurately if your flows contain conditional branches (if/else), loops, or dynamically determined approvers. Creating a script to predict a flow's path could introduces severe technical debt and fragility.

Since Flow Designer does not have a native, OOB method to "look ahead" (as far as I know) and predict future approvals before the engine executes those specific steps,I would avise to leverage flow stage, this doesn't do exactly what your trying to achieve but could answer the requirement

Often, business users ask for the names of future approvers when what they actually need is an understanding of where the ticket is in the overall process lifecycle.

  • How it works: Implement robust, granular Flow Stages (e.g., "Awaiting Sales Management Approval," "Awaiting Legal Review," "Awaiting Finance Approval").
    Stages are 100% OOB and render beautifully on the Service Portal (via the Stage renderer) and the classic UI.
  • The Trade-off: It shows the phase rather than the specific person. You can pair this by exposing a Knowledge Base article or a simple UI link that shows the standard approval matrix for that contract type. This requires zero custom code, zero technical debt, and pushes the business to adopt standard platform capabilities.

    If this doesn't fit, you could also pre-generate the approvals to get visibility or try to introduce Decision builder in the approval generation to get something easier to read ?

    Regarding the third point, this related to Governance (and a technical board can really help to avoid technical debt)
    I would also suggest (if you haven't already) to look at this 
    https://mynow.servicenow.com/now/best-practices/assets/businesssmart-customization

    Let me know if this help 🙂
0 Helpfuls