--- sourceDocument: Brazil ServiceNow AI Platform Capabilities sourceDocumentLink: https://www.servicenow.com/docs/r/servicenow-platform Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil ServiceNow AI Platform Capabilities ft:clusterId : - platcap bundleId : - platcap workflow : - Platform --- # Reconciliation rules # Reconciliation rules {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 5 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Reconciliation rules Reconciliation rules in ServiceNow govern which discovery sources are authorized to update Configuration Item (CI) attributes, ensuring data accuracy and preventing conflicting updates. These rules are essential when multiple discovery sources, such as Event Management, Import Set, Manual Entry, and Tivoli, interact with the createOrUpdateCI() API to maintain CI data. Show full answer Show less There are two types of reconciliation rules: ## Key Features * **Static reconciliation rules:** Legacy rules that assign priority to discovery sources for updating CI attributes. They define which sources can update specific attributes and establish precedence order. These rules can be applied at both parent and child class levels and are stored in the *Reconciliation Definition \[cmdbreconciliationdefinition\]* table. * **Dynamic reconciliation rules:** Rules based on attribute values processed by CMDB 360 rather than fixed source priority. CMDB 360 aggregates data, and dynamic rules select values (e.g., largest or most reported) across sources. Only one dynamic rule can exist per class attribute, and these rules require enabling CMDB 360. They are stored in the *Dynamic Reconciliation Definitions \[cmdbdynamicreconciliationdefinition\]* table. ## Applying Reconciliation Rules * **Precedence:** Dynamic reconciliation rules override static rules for the same CI attribute. * **Authorization scopes:** * Static rules can authorize a discovery source to update all attributes in a class or only specific attributes by listing them explicitly. Specific attribute rules override broader authorizations. * Child class reconciliation rules override parent class rules for shared attributes, whether static or dynamic. * Multiple static rules can authorize different sources to update the same attribute without excluding each other, with enforcement to prevent overwrites between sources. * **Domain Separation:** When enabled, reconciliation rules can be scoped per domain. Parent domain rules apply to child domains unless overridden, and domain-specific versions of rules are visible and applied accordingly. ## Examples * Discovery source exclusively authorized to update the `name` attribute in the `cmdbcicomputer` class and its child classes. * ServiceWatch exclusively authorized to update the `name` attribute and all attributes (if attribute list is empty) in the `cmdbcilinuxserver` child class, overriding parent rules. ## Practical Use and Benefits Using reconciliation rules enables ServiceNow customers to: * Maintain CI data integrity by controlling which discovery sources can update specific attributes. * Resolve conflicts between multiple data sources by defining clear precedence and authorization. * Leverage CMDB 360 for advanced, attribute-value-based reconciliation with dynamic rules. * Customize rules at both class and attribute levels to fit complex organizational needs. * Manage CI updates effectively across different domains when Domain Separation is used. ## Additional Configuration ServiceNow customers can create reconciliation rules (both static and dynamic) and specify data refresh rules to identify stale CIs per discovery source. This enables updating stale CIs by lower-priority authorized sources, further enhancing CI data reliability. Reconciliation rules determine which discovery sources can update CI attributes.{#r_ReconciliationRulesPrinciples__ph_ReconciliationShortDesc} Discovery sources, such as EventManagement, ImportSet, ManualEntry, and Tivoli, are used with the [createOrUpdateCI()](https://www.servicenow.com/docs/access?context=c_IdentEngineScriptAPI&version=brazil&pubname=brazil-api-reference&ft:locale=en-US) API to simulate manual updates to CIs. Without reconciliation rules, discovery sources can overwrite each other's updates to attribute values. There are two types of reconciliation rules: Static reconciliation rules : Static reconciliation rules are the legacy reconciliation rules that set priorities for the various discovery sources for updating CI attributes. Static reconciliation rules specify which discovery sources can update class attributes, and the precedence order among these discovery sources. When creating static reconciliation rules, ensure that there is a reconciliation rule for each discovery source that is authorized to update an attribute. Reconciliation rules can be defined at the parent and the child class level. Static reconciliation rules are stored in the Reconciliation Definition \[cmdb_reconciliation_definition\] table. Dynamic reconciliation rules : Dynamic reconciliation rules are based on attribute values processed by [CMDB 360](https://www.servicenow.com/docs/e7rfhxjWpf95Qna3XD7Gog "CMDB 360 retains complete history about discovery sources and proposed values, involved in updates of CI attributes. Use CMDB 360 data to track how the CMDB is populated by various discovery sources at the CI attribute level. Also, to revert CI updates from a specific discovery source, or to recompute attribute values using updated reconciliation rules.") rather than on discovery source priority. First, CMDB 360 processes the current payload data into the CMDB 360 data store. Then, applying a dynamic reconciliation rule, IRE selects the largest or most reported value, for example, across all discovery sources. Because dynamic reconciliation rules leverage CMDB 360, you must enable that feature to use dynamic reconciliation rules. Creating dynamic reconciliation rules can be useful, for example, if it becomes difficult to set priority order for multiple discovery sources. Only a single dynamic reconciliation rule can exist per class attribute. Dynamic reconciliation rules are stored in the Dynamic Reconciliation Definitions \[cmdb_dynamic_reconciliation_definition\] table. ## Examples of static reconciliation rules {#r_ReconciliationRulesPrinciples__section_mzm_tlg_q5b} The following sample static reconciliation rules are created for the cmdb_ci_computer class and its cmdb_ci_linux_server child class: 1. Discovery is exclusively authorized to update the name attribute in the cmdb_ci_computer class. Because reconciliation rules are derived by child classes from parent classes, this rule also authorizes Discovery to update the name attribute in any child classes for the cmdb_ci_computer class. 2. ServiceWatch is exclusively authorized to update the name attribute in the cmdb_ci_linux_server class. 3. ServiceWatch is exclusively authorized to update all attributes in the cmdb_ci_linux_server class, as configured by leaving the Attributes field empty in the rule. {#r_ReconciliationRulesPrinciples__ol_gk5_gg4_ft} See [Create a CI reconciliation rule](https://www.servicenow.com/docs/0pT4QlDmKokSjVO3j6FBJw#create-reconciliation-rule "Create a static or a dynamic CI reconciliation rule.") for details about creating a static reconciliation rule that, for example, authorizes a discovery source to update a specific attribute such as name. ## Using reconciliation rules {#r_ReconciliationRulesPrinciples__section_dtq_nty_p5b} As you create reconciliation rules, keep in mind the following principles which are designed for flexibility and the refinement of rules at the attributes level: Precedence of dynamic reconciliation rules : When both, static and dynamic reconciliation rules exist for the same CI attribute, the dynamic reconciliation rule takes precedence over the static reconciliation rule. Authorization for all attributes in a class : A static reconciliation rule lets you authorize a discovery source to update all attributes in a class. However, this authorization can be overridden for some of the attributes by rules for child classes in which specific attributes are listed. For example, if only example rules #1 and #3 above are created, then Discovery is authorized to update the name attribute in the cmdb_ci_linux_server class. ServiceWatch is authorized to update all other attributes in the class except for the name attribute. To override the authorization of Discovery to update the name attribute, example rule #2 above is added to specifically authorize ServiceWatch to update the attribute. Authorization to only specific attributes in a class : To authorize a discovery source to update specific attributes in a class, create a static reconciliation rule for the discovery source, and list these attributes in the rule. A rule that grants access to specific attributes in a class overrides other static reconciliation rules with an empty attribute list that grants access to the entire class. Example rule #1 above grants Discovery with exclusive authority to update the name attribute of the cmdb_ci_computer class. All other discovery sources are prevented from updating the name attribute of any CI in the cmdb_ci_computer class. Child class rules overrides parent class rules : Any reconciliation rules defined for a child class override the rules defined for its parent class. So if an attribute of a derived rule is overridden by a child's class rule for a specific class, then the derived rule has no effect on that attribute. This behavior applies also when the child's reconciliation rule is static and the parent's rule is dynamic (dynamic reconciliation rules have precedence over static reconciliation rules when they are for same level class). For example, rule #1 above lets Discovery update the name attribute in the cmdb_ci_computer class and all of its child classes. However, rule #2 for the cmdb_ci_linux_server child class, which overrides rule #1 for the parent class, explicitly authorizes ServiceWatch to update this attribute in the child class. As a result: * Discovery cannot update the name attribute of the child cmdb_ci_linux_server class. Only ServiceWatch is authorized to update this attribute. * Discovery is authorized to update the name attribute of CI records in all other child classes of the cmdb_ci_computer class. {#r_ReconciliationRulesPrinciples__ul_y1x_yzy_3t} Overlapping static reconciliation rules : Static reconciliation rules that authorize different discovery sources for the same attributes of the same class can coexist and do not exclude each other. For example, assume the following rule is added. It is similar to example rule #1 above but authorizes a different discovery source: ServiceWatch is authorized to update the name attribute in the cmdb_ci_computer class. Like example rule #1 above, this new rule applies to the name attribute in the cmdb_ci_computer class so both Discovery and ServiceWatch can update the attribute. Any reconciliation rules are enforced to prevent the discovery sources from overwriting each other's updates. For more information about reconciliation rules, see the [CMDB - Data Precedence Rules Understanding the CMDB data precedence rules and troubleshooting \[KB0756709\]](https://support.servicenow.com/kb_view_customer.do?sysparm_article=KB0756709) knowledge base article. ## Domain separation If Domain Separation is enabled, then you can scope reconciliation rules to specific domains. Rules of the parent domain, if not overridden, apply to CIs of child domain. All rules that are visible to a domain are applied, and a rule overriding the parent domain displays the child domain version. * **[Create a CI reconciliation rule](https://www.servicenow.com/docs/0pT4QlDmKokSjVO3j6FBJw#create-reconciliation-rule)** Create a static or a dynamic CI reconciliation rule. * **[Create a data refresh rule](https://www.servicenow.com/docs/dZahDgKN0ym6V_k4npw8WA)** Specify data refresh rules to determine if a CI is stale for a specific discovery source. Such CIs can then be updated by a lower-priority authorized discovery source.