Dependency declaration for service orders

Gargichatterjee
Tera Contributor

Hi,

 

I want to define dependency among the service orders (for the CFS and RFSs), which are getting generated after decomposition. Currently there is no sequence maintained for the service orders. So all the service orders are getting executed parallelly. I want to define a sequence and dependency among the SOs. Please suggest how to do that.

1 ACCEPTED SOLUTION

I highly recommend to go through the NOW Learning modules for Order Management which covers this topic.

 

The staggered approach is only applicable if there is a decomposition involved and this will be subject to your Catalog Definition and Requirements.

 

Assuming, there is decomposition involved you will need to define a char on say the parent CFSS.

On the Spec Relationship between the CFSS and RFSS, you can define a decomposition rule such that the decomposition happens only if a value is set for the char.

 

The value for this char would need to be set via the subflow by updating the Order Char record for the domain order for the parent CFSS. This step can be done after the External API call in your example.

 

Once the char is set, the decomposition condition will be satisfied to create the domain order for the RFSS, invoking the associated orchestration flow.

 

Note: Defining a Char on the CFSS (or rather any Spec) just to control dependencies is not the best way of modelling as the Catalog Definition and hence the Inventory records get polluted with unnecessary data that is not relevant beyond it's temporary purpose. As such, consider the approach with overall implementation in mind.

View solution in original post

13 REPLIES 13

ShashankInamdar
ServiceNow Employee
ServiceNow Employee

Hi @Gargichatterjee , are you referring to dependency between orchestration flows (subflows) associated with these CFSS/RFSS?

The decomposition itself i.e. Service orders for the CFSS/RFSS cannot be sequenced, as these are created by OMT based on Catalog Definition and satisfaction of decomposition rules.

Can you confirm the dependency you are trying to achieve?

Hi @ShashankInamdar , for example if I want to have an order which will have 4 RFSs. With all 4 RFSs, 4 subflows are associated which will be executed. For RFS3 to be executed, suppose I need the response of an external API which is getting called when the subflow is executed which is associated with RFS1. In that case I need to define a dependency between RFS1 and RFS3, so that RFS3 always wait till RFS1 is completed or in other words, RFS3 is dependant on RFS1 to be executed. 

In these cases, I want to define dependency among the service orders.

 

Thanks.

 

 

I can think of either

 

  1. Horizontal Relationship
  2. Staggered Decomp.

Hi @Gargichatterjee ,

There could be multiple ways to achieve this.

But the below are common patterns that can be used -

[1] 'Order Stage' field

Domain Orders have the Order Stage field.

Once the External API response is received you can add a step in the RFSS1 subflow to update the 'Order Stage' field on RFSS3 in that Order.

Once the Order Stage field on RFSS3 is set,

(a) Either you can control to invoke the subflow for RFSS3 by having Stage as an input field in the Decision Table, such that only when the particular stage value is set the subflow gets invoked

OR

(b) Let the subflow for RFSS get invoked irrespective of the stage value, but you add a 'Wait for Condition' until Order Stage = xyz and only then proceed with the further steps.

 

[2] Staggered Decomposition

Subject to how the Catalog definition/structure is, you may be able to control this via decomposition condition.

In this option, once the External API returns a value - a characteristic is set on the parent of RFSS3 and in the decomposition condition of parent - RFSS3, this char is used. Thus, the decomposition only happens after the char value is set which is after the API call. And hence only then the Subflow for RFSS3 gets called.

But in this case, you will be adding a char to the Catalog model which may not be always the right way of doing it.