Flow Designer and Business Rules for Life Cycle Stage and Status

Darlene York
Tera Contributor

I have a step in my flow to update the CI Life cycle stage and status in a flow.  I keep getting an error “Error occurred while updating record: null”.  In the log it says its failing because of an invalid Life Cycle Stage and Status combination.

 

We have determined that the business rule “Life Cycle Stage and Stage Status combination” is clearing out the variable and failing before the new value can be updated with the value specified in the flow update record.

We kicked around the idea of turning off the business rule when flow is running, but this could be an issue if a CI needs to be updated outside the flow.

 

I was wondering if anyone has a better solution.

Thank you

1 ACCEPTED SOLUTION

The mappings themselves can be modified, but I believe that is only prior to activation (I think?).  What cannot be modified at all is the Lifecycle Stage and Status values themselves, and the list of available values for a given table.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

View solution in original post

7 REPLIES 7

CMDB Whisperer
Mega Sage
Mega Sage

I would highly recommend avoiding any updating of these fields directly on CIs or Assets.  While it is true they have added a business rule that in theory will keep the legacy CI and Asset status fields up to date, the reality at this point is that you are still better off updating the legacy fields and allowing one-way synchronization to the Life Cycle Stage and Status fields via the Life Cycle Mapping objects.  And yes, one of the many issues with CSDM Life Cycle is that if  you are going to update it directly, you must make the update to both fields simultaneously in the same database commit.  I would NOT recommend disabling the business rule that validates this!  Unfortunately the result is that there are several areas, including in a list view edit operation, where it is not possible to edit them because there is no function available to edit them simultaneously.  And even if you were able to, it is most likely that you will find your CI and Asset legacy status fields are not upgraded automatically, which is going to affect the correct operation of other platform capabilities that rely upon or update the CI and Asset status fields.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Thank you for your reply. 

 

Would you recommend making new mapping from the legacy fields?  One of my requirements is to make the Lifecycle Stage Operational, Life Cycle Status Pending Retirement and Operational status Operational.  I can do it if Im updating a CI manually, but not thru automation in Flow Designer.

 

I think at one point I observed there wasn't a default mapping that mapped to Pending Retirement, and I made a post here that mentioned that.  There didn't seem to be a great solution for this OOB, and I don't think there is a clear, distinct legacy field value that maps directly and determinatively to Pending Retirement.  It's the one gap in the CI lifecycle using standard fields.  The only CI class that has a mapping for it is Service.  But it makes good sense to have a mapping.  Problem is I haven't been able to come up with a good combination of standard Install Status, Hardware Status/Substatus, Operational Status, or anything else that definitively maps to Pending Retirement.  Perhaps there is one I haven't considered.  Or perhaps, more likely, there is a need for, dare I say... a custom value in one of the legacy fields (cringe) that could be mapped to Pending Retirement.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.

Back to your real issue in Flow Designer, is it trying to do this in two distinct actions?  That could be the problem.  I'm guessing that if you are making these updates in two different no-code actions, they might be committed separately, which would indeed cause this issue to occur due to the business rule.  If, however, you did a scripted action that updated both fields and then called the update() method, this issue should not occur.


The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.