Orchestration Dependencies Across Orders

You can set up orchestration orchestration dependencies across orders using the Related Order scope in an orchestration dependency definition.

Sometimes it makes sense to split a large order into smaller ones (to avoid governor limits, for example, or to track requests individually). Doing so sometimes means that tasks that depend on each other end up in different orders.

For example, one order contains a Bill Customer task that you don't want to run until an Activate Service task in a different order is complete.

Industries Order Management can handle those dependencies, allowing you to configure your orchestration so that tasks that depend on others will wait for them, even if they're in different orders.

Let's a simple example. In the following image, the Activate Service task in Suborder 1 must finish before the Bill Customer task in Suborder 2 runs.

Although the tasks are in two separate orders, Order Management handles the dependency smoothly. The customer isn't billed until after the service is activated.

Note As explained in the Important Considerations section, in this case, you must submit Sub Order 2 before submitting Sub Order 1.

Important Considerations

You must submit orders in the right sequence: Submit the orders in the sequence that their tasks are run. For example, looking at the earlier image, if you must activate the service before billing the customer, then you must submit the order with the Activate Service task before submitting the order with the Bill Customer task.

Two orders can't depend on each other. In the following image, a task in Suborder 1 depends on a task in Suborder 2 and vice versa. This configuration simply won't work.