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

Hi @ShashankInamdar 

Thanks for the options. Meanwhile I read about compatibility rules, and I understood that we can define a horizontal relationship among the service orders through it. Which is in my opinion can define some sequencing of the service orders.

I implemented it but it is not working as expected. In the demo video as well, the Fulfilment agent needs to manually fill the required service orders. Can you please throw some light on it?

If it can work then we do not need to any customization through flows.

 

Thanks.

Hi @Gargichatterjee , 

If you configure Compatibility Rules it does not automatically enforce dependencies during orchestration/fulfilment. You may choose to add the logic in the subflows via the relationship established to determine if the dependent or pre-requisite Service Order is completed or in a certain stage.

 

Also, you need to manually fill the required Service Order only in 2 scenarios -

[1] where the relationship was not expressed at Order Line Item level at the time of order submission in the payload or via workspace

OR

[2] where the relationship is between decomposed specifications which cannot be expressed at the time of Order submission.

Hi @ShashankInamdar 

I am going by the staggered decomposition. Can you please let me know how to set the value of the characteristic through subflows 🙂

As I am very new to Servicenow so need help.

Thanks

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.

That's great insight you mentioned in the note, @ShashankInamdar . 🙂

 

Doesn't it give birth to the requirement of having decomposition not only based on product model chars but also something broader?

 

Also, I would love have decomposition rules based multiple and complex conditions.

 

--

Molay