Deactivation of the "Sync Ops Status for CMDB CI" business rule<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: block; max-width: ; width: auto; height: auto; } } Problem: In the Xanadu release, the Sync Ops Status for CMDB CI was deactivated out of the box. Some customers are used to having the behavior of that business rule as part of their workflows, and are asking if they can turn it back on, if there is a replacement, or why this was done. Reason for deactivation: The logic within the business rule is designed to check if there is a mismatched state between the Operational Status field and either the Install Status or Hardware Status fields on a cmdb_ci record. If the record extends from cmdb_ci_hardware, then Operational Status is compared against the hardware status & substatus fields, otherwise it is compared with the install status field (this KB will refer to both of these as the "alternate field" below). However, this is only focused on the Retired state, and does not serve as a universal status sync between Operational Status and the other two statuses. Additionally, the logic of this sync operation uses some hard-coded values and can result in incorrect status for a record. The business rule uses the following steps on every record update: Is operational status set to retired and alternate field is non-retired, or is alternate field retired and operational status is not? If so continue.If operational status changed during this record update: If operational status is "Retired", set alternate field to "retired"If operational status is anything else, set alternate field to "Installed" (and "in use" for hardware cases) If operational status didn't change: If the alternate field is "retired", set operational status to "retired"If the alternate field is anything else, set operational status to "non-operational" From the emphasized sections above, it follows that there are many combinations wherein a record update touches only one of the two fields, and not all cases will align with "installed" or "non-operational", and since the scope of this sync was so narrow, really the only "happy path" is for cases where a workflow updates one of the two fields to "retired" and the customer wants the ops/alternate field pair to align on retired state. Can customers re-activate this business rule? Customers are welcome to re-enable if they feel the rule aligns with core functionality they need, but they are strongly advised to instead create a specific sync business rule that more closely matches what they want from this sync. Activating this rule allows all the cases mentioned above which result in incorrect status updates outside of the core retired-matches-retired case. Better Options Applying specific run conditions Currently the business rule runs on every update. The condition builder for when to run the rule allows for limiting the update operation to more specific retirement cases, such as the example below: Replacing the business rule with a simpler version Potentially combined with the above, if customers want to synchronize a set of values, they can write a new rule with optional triggers like above that explicitly lists the synchronization cases in the script body. Replicating what the current rule does would only require logic such as "if operational status changed and is retired, set install status to retired" and "or if install status changed and is retired, set operational status to retired". This could be extended for more values as needed.