Optimizing Maintenance for Step-Based Request Fulfillment in a Software Store Catalog

[Community Alums]

I am developing a software store catalog where each software item is created as a separate catalog entry using the new interface. The process leverages the out-of-the-box "step-based request fulfillment" flow, which retrieves assignment and approval group details from a configuration table and processes them at runtime. Currently, this requires creating separate assignment and approval records for each catalog item. Since most software items are assigned to and approved by the same team, this setup creates significant maintenance overhead, as new configuration records must be added to the table whenever a new software catalog item is introduced. Given that using this flow is an architectural requirement.

What would be the most efficient approach to reduce maintenance efforts and streamline the process?

[Mark Manders]

There is none. But you are looking for a solution that isn't OOB available. Because the OOB solution is to create config records for each item. 

You have to change the logic that is looking at the config items. Where those are looked up, you need to apply the 'default' logic, when no record is found. That way, you always have the default, unless it's an exception and for those you have the config records.

[Community Alums]

@Mark Manders I understand the approach you’re suggesting, but here’s the situation:
The main flow, "Step-Based Service Request Fulfillment," which triggers the stage lookup sub flow, "Service Fulfillment Steps Base Flow."
This sub flow, "Service Fulfillment Steps Base Flow," performs a lookup in the sc_service_fulfillment_stage table and filters records based on the catalog item ID retrieved from the request.

If I modify the subflow configuration to use default , it would require maintaining separate records and Item, more importantly, altering the out-of-the-box (OOB) subflow Service Fulfillment Steps Base Flow provided by ServiceNow.

My primary concern is to avoid reconfiguring the OOB functionality and to eliminate duplication in the sc_service_fulfillment_stage table for creating two Or more records for the same task and mapping with different catalog items. 

Is there an alternative way to achieve this operation, even if it requires additional configuration? I am open to exploring that if necessary.

[Mark Manders]

I have given several possibilities and each one isn't feasible because it changes OOB processes. If you want to stay OOB, you will just need to create the config records for each item. That's how it works.