Best Practices for Creating a Generic Flow for Catalog Items

[sattar3]

Hello Everybody,

We have a requirement to create a generic flow for catalog items that can be reused for multiple catalog items in the future. Based on the RITM state, we need to set the corresponding stage.

Please suggest the best practices for implementing this and let us know if there are any potential drawbacks after publishing this subflow/flow.

Mapping of State to Stage:

• Open → Order Under Review
• Work in Progress (WIP) → Fulfillment
• Pending Approval → Waiting for Approval
• Fulfilled → Delivery
• Closed → Closed Complete

Thanks,

Sattar

[AndersBGS]

Hi @sattar3 

Why are you utilizing the "get catalog item variables"? By doing this, you are assigning the flow to specific catalog item instead of having a generic flow for several catalog items?

[Ankur Bawiskar]

@sattar3 

I will recommend individual flows for your items rather than combining.

If some requirement changes in future for any of those items you will have to maintain that single flow and make changes to it.

Then you will have to test it for your items along with the other items where requirement was not changed.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Brad Bowman]

You can't use the Get Catalog Variables action unless you use the same variable set(s) for every Catalog Item that uses this flow.  See this article I wrote on how to work around this, and deal with less straight-forward things like Catalog Tasks:

https://www.servicenow.com/community/itsm-articles/using-workflow-studio-flow-designer-flows-for-mul... 

You mentioned that the Update Record action is not working in your client instance.  It appears as though the Update Multiple RITM action is also not working, so it sounds like if you figure out the root cause, all will be fine.  Also try (Update Record) setting a different field on the RITM to see if that works.  Stage can sometimes be more difficult to work with than other/normal RITM fields. 

[mugi-san]

Hi @sattar3 

​Based on my experience, "stage" and "state" do not always have a one-to-one correspondence. Consequently, I believe that attempting to generalize the flow using the rules provided will likely result in intricate, item-specific branching logic (specifically, complex mapping processes between stages based on various conditions).

​To achieve the requirements you’ve presented, I feel it is necessary to move away from purely technical implementation for a moment. Instead, we should reach an agreement with the business side regarding the operational workflow—ensuring it can be managed through a simplified set of stages and states.

​In my past experience, attempts to make processes "universal" by providing numerous templates or variable sets led to conflicting requirements between catalog items just months later. It also resulted in Record Producers that were so bloated they became a burden for users to operate.

​In every case, we failed to achieve true flow generalization.

​As a potential alternative, it might be better to redefine what we call a "universal flow." We could create various catalog items and Record Producers as microservices, develop subflows to execute combinations of them, and then build a master flow to call these components. In this model, "generalization" means that a human or an AI simply toggles flags to determine which processes are triggered.

Regards.