Make client requirements part of every matching order.

Imagine a client asks you to include one bottle opener in orders worth at least $150. Configure an order-created rule for that client, the qualifying total and the absence of the gift SKU. When the conditions match, SIP adds one bottle opener as an order line for fulfillment.

This is an illustrative example of a supported rule. Choose the actual client and an active, eligible product from your catalog. The threshold uses the store’s currency; the rule does not convert currencies. Stock allocation and availability still determine fulfillment.

The missing-gift condition and duplicate-SKU check prevent this example from adding a second gift when that SKU is already in the order. An order-created rule does not automatically remove the gift after a later change to the order total.

A different client may want high-value orders checked before fulfillment. Combine a client condition with an order-total threshold, then apply a hold with a review note.

Choose conditions and actions around the decision your team actually makes. A hold records the need for review; it does not approve or release the order on its own.

Simulate supported conditions against a bounded sample of order history and inspect matching and nonmatching examples. Use the explanation view to see which conditions passed for an order.

Test mode records what the rule would apply without executing the actions. Review the result before enabling live actions. A sample helps validate the rule; it is not a promise that every future order will match your expectations.

Rule executions record their outcome, and applied actions carry rule attribution in the audit history. When a gift was added or an order held, your team can inspect the recorded action.

Automation handles supported triggers, conditions and actions. Warehouse configuration separately defines standing policies such as client-specific packing checks. Use the two together to describe what should happen and how the floor should verify it.