Skip to main content

Object Schema

Cloudaware CMDB schemas are implemented as Salesforce/Force.com custom objects (sObjects) delivered through Cloudaware managed packages. Each configuration item (CI) type maps to a namespaced object, and each object exposes fields for identity, lifecycle, configuration, ownership, tags, relationships, and module-specific context.

Use this reference as the CMDB-specific entry point for understanding schema conventions. For the conceptual model, see Data Model. For the platform-level package model, see Force.com & Cloudaware Packages.

Object Categories​

CMDB objects represent cloud resources, on-prem assets, applications, findings, events, and other managed entities. Common object categories include:

  • Provider containers: accounts, subscriptions, projects, organizations, regions, and compartments.
  • Compute and platform resources: instances, virtual machines, containers, clusters, functions, and hosts.
  • Storage and data resources: volumes, disks, buckets, databases, queues, topics, and backups.
  • Networking and security resources: VPCs, subnets, load balancers, network interfaces, security groups, firewalls, certificates, and identities.
  • Business and application records: applications, tiers, services, owners, business units, and customer-defined objects.
  • Findings and events: vulnerabilities, compliance findings, alerts, incidents, and change events.

Cloudaware object API names usually include a managed package namespace and a custom object suffix, for example:

Conceptual ObjectExample API Name
AWS AccountCA10__CaAwsAccount__c
AWS EC2 InstanceCA10__CaAwsInstance__c
AWS EBS VolumeCA10__CaAwsVolume__c
AWS Instance-Volume LinkCA10__CaAwsInstanceVolumeLink__c
ApplicationCA10__CaApplication__c
Application TierCA10__CaApplicationTier__c
Kubernetes ClusterCA10K__CaKubernetesCluster__c
Vulnerability FindingCA10__CaNessusVulnerability__c

For more object-model context, see Objects and sObjects and Object Relationships.

Field Patterns​

CMDB fields are Salesforce fields on the underlying sObject. Field availability varies by object type, provider, enabled integrations, and Cloudaware package version, but most objects follow common patterns:

  • Identity fields: Salesforce Id, Name, provider-native IDs, and stable Cloudaware identifiers such as CA10__caUuid__c where available.
  • Lifecycle fields: timestamps and state indicators such as CA10__disappearanceTime__c, where a null value typically means the resource is still active in the source system.
  • Location and ownership fields: account, subscription, project, region, availability zone, owner, team, business unit, environment, and application context.
  • Configuration fields: size, type, SKU, engine version, operating system, runtime state, network settings, encryption status, and provider-specific properties.
  • Tag and metadata fields: cloud-native tags, normalized tags, CaTags, enrichment outputs, and custom fields.
  • Module context fields: cost, compliance, vulnerability, backup, monitoring, patching, and incident indicators where those modules are enabled.

For more detail on common field groups, see Attributes.

Relationships​

Relationships connect CMDB records into a graph used for navigation, impact analysis, reporting, automation, and policy scoping. Cloudaware uses standard Salesforce relationship patterns:

  • Master-detail relationships for strong parent-child dependencies.
  • Lookup relationships for flexible references between independently managed records.
  • Junction objects for many-to-many relationships, such as instances linked to volumes, interfaces, security groups, or application tiers.

Common relationship patterns include:

  • Account, subscription, project, or organization to regional resources.
  • Compute instances to volumes, network interfaces, images, security groups, and monitoring records.
  • Applications and tiers to compute, databases, queues, load balancers, and other supporting services.
  • Findings, alerts, tickets, and change events to the affected CI.

For conceptual relationship guidance, see Relationships. For Salesforce-level examples, see sObjects and Object Relationships.

Schema Discovery​

Use the following docs and product areas to identify the object and field schema behind a CMDB view:

  • CMDB Navigator to locate the provider, category, and object type in the UI.
  • CMDB List Views to inspect available fields and filters for a specific object type.
  • Browse Objects to build queries, validate scopes, and inspect fields used in saved views and reports.
  • Salesforce Reports for CMDB to build formal reports over selected CMDB objects.
  • Salesforce Setup → Object Manager in your Cloudaware org to inspect exact object API names, field API names, relationships, record types, and package ownership.

Provider Coverage​

Provider-specific docs describe which services are discovered and represented as CMDB objects:

For coverage of other integrations, see the Supported Objects section in the relevant guides in Integrations.

Customization​

Customers can extend CMDB schema where supported by adding custom objects, custom fields, calculated attributes, enrichment rules, and layout changes. Keep custom schema aligned with Cloudaware-managed objects so reporting, automations, and module integrations continue to work as expected.

For customization guidance, see:

Notes and Constraints​

  • Exact object and field availability depends on the Cloudaware package version, enabled modules, and connected integrations.
  • Some object and field labels are abbreviated to fit Salesforce managed package limits.
  • Provider-native IDs are not always globally unique; combine them with account, subscription, project, region, or Cloudaware UUID fields when building durable integrations.
  • Deleted or disappeared provider resources may remain in CMDB for history, audit, or reporting; use lifecycle fields and active/deleted filters when building queries.
On this page