Skip to main content

Normalization Rules

Cloudaware uses normalization rules to harmonize provider‑specific objects and fields into a unified CMDB schema before enrichment and customization are applied.

Overview​

Cloudaware aims to support and present a consistent object and attribute model across clouds and tools. To do so, Cloudaware leverages naming conventions for objects and fields (attributes), field-mapping strategies, globally unique IDs to avoid duplicate CIs, and standardization for units and enums.

Object Naming Conventions​

When creating a new object, Cloudaware uses the following rules:

  • Label: CamelCase with spaces (e.g., {Provider}{Service}{Object}).
  • Plural Label: plural form of the Label value.
  • Object Name: CamelCase without spaces (e.g., Ca{Provider}{Service}{Object}).
  • Record Name: based on the primary record identifier, for example, instance name or ID.

Where applicable, record type normalization rules on the object are used asd follows:

  • Existing Record Type must remain set to Master.
  • Record Type Label must use CamelCase with spaces and start with a capital letter.
  • Record Type Name must use camelCase without spaces, start with ca, and follow this structure: ca{Provider}{Service}{Object}{RecordType}.
  • In abbreviations, only the first letter is capitalized (e.g., caAlibabaCloudSlbSecurityPolicyApplication).

Additionally, search and reporting indicators are enabled on the object.

Field Mapping Strategies​

Cloudaware maps cloud‑native fields to CMDB attributes:

  • IDs (for example, instanceId, vmId, id) → provider ID fields and/or CA10__caUuid__c.
  • Names and descriptions → Name and description fields.
  • Type, size, and region → normalized fields in the CMDB (for example, instance type, Region, Availability Zone).

Cloudaware stores tags/labels as is:

  • Multiple tag keys (for example, Owner, owner, team) may exist in the CMDB but you can map heterogeneous tags into common ownership or tag dimensions (through Tag Analyzer and fuzzy caTags normalization).
  • Environment tags (Env, environment, stage) can be mapped into a single environment field.

Units and Formats​

Cloudaware normalizes capacity and size fields:

  • Sizes are stored in consistent base units (for example, bytes or GiB) with clear display formats.
  • Decimal/thousands separators and numeric formats are aligned across different providers.

Cloudaware normalizes enums:

  • State names (for example, running, RUNNING, Started) are aligned into a standard set of states.
  • OS/engine names and versions are also normalized.

Conflict Resolution and Precedence​

When multiple sources can set the same field (for example, cloud provider vs monitoring vs custom collectors), normalization defines precedence rules such as:

  • Preferred sources per field (for example, provider → security tool → custom collector).
  • Tie‑breaking rules when values disagree (for example, newest timestamp wins).
  • Fallback behavior when a higher‑priority source is temporarily unavailable.

These rules ensure that each CMDB field reflects a single, authoritative value rather than conflicting inputs. If any discrepancies with these rules are detected, contact Cloudaware Support at support@cloudaware.com.

Custom Mapping Extensions​

You can introduce additional normalization logic via:

  • Custom fields and formulas.
  • Workflows and automation that reshape or override provider values.
  • Custom collectors feeding pre‑normalized data into CMDB.

For provider‑specific mapping details and API names, see also: