Best Practices for Creating a Generic Flow for Catalog Items
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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:
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
