Patch - fulfilment flows restriction

[bmedic]

Hi @ShashankInamdar , I am not able to post this question on your DYK article about the patch (Change & Cancels in Order Management)

First of all, thank you for your article. I find it very useful.

I have a question: what would be the best approach to restrict the fulfillment flow to run on some of the domain orders during the Patch?

I am dealing with a rather big product model, and would like that on the patch; not the entire model is reprovisioned (not all fulfillment flows are triggered on the patch).

The customer can send a Patch change only for one part of the product, but when submitting it, the entire fulfilment is re-triggered.

Thanks in advance.

[wojasso]

Hi @bmedic

When you send a patch (change or cancel) in Order Management, the engine treats it as a full re‑provisioning by default – it runs every fulfillment flow associated with the order regardless of which components were actually modified. There is no out‑of‑the‑box flag to run flows for only a subset of items. The best way to control this behaviour is to add gating logic to your fulfillment flows so they evaluate what has changed before executing.

Here are some approaches that are commonly used:

• Use conditions on the flow trigger. In each fulfillment flow’s trigger condition or first step, check the Change type and the order line item fields. For example, you can query the sn_chg_change_item or OMChangeAction records to determine whether a particular domain or child product is part of the patch. If the changed item is not relevant, simply exit the flow.
• Create separate flows for patch operations. Instead of using the same fulfillment flow for both new orders and patches, create a dedicated Change flow type. The patch flow can iterate over only the changed components and call the appropriate provisioning subflows. This gives you precise control over what is re‑provisioned.
• Leverage the Change and Cancel framework. The “Change & Cancels in Order Management” plugin provides APIs such as sn_order_change.RuleEvaluator and sn_order_change.Utils.isPatch() that tell you whether the request is a patch and which specifications were added/removed/modified. You can use these in a decision or script step to decide whether to proceed.
• Restrict by domain or product model. If you have domain separation enabled, set the sys_domain on your fulfillment flow or use a domain‑aware condition so that only flows in the matching domain are triggered. For large product models you can also break down the model into nested components and attach flows only to the components that should respond to patch updates.

The key point is that the patch API doesn’t automatically skip unaffected flows. Adding conditional logic or using separate patch flows is the recommended way to ensure that only the relevant portions of a large product model are re‑provisioned during a patch.

This response was drafted with the help of AI and briefly reviewed by a human. Please excuse any errors or formatting issues.

💥 Was this answer useful? 👉 If so, click 👍 Helpful 👍 or Accept as Solution ✅ 💡🛠🧠🙌