sObjects and Object Relationships

Cloudaware runs as a managed application on Salesforce, so CMDB records, module data, reports, and API queries are stored and exposed through Salesforce data-model concepts.

This guide describes sObjects because they are the underlying object types behind Cloudaware configuration items, integrations, and relationships. Understanding this Salesforce layer helps you interpret Cloudaware API names, write SOQL queries, build reports, and trace how assets depend on each other across CMDB.

What Are sObjects

In Salesforce (Force.com), sObjects are the fundamental data entities that represent records in the Salesforce database. Each sObject corresponds to either a standard object (e.g., Account, Contact, Case) or a custom object (API name ends with __c, e.g., BusinessUnit__c). Developers use sObjects to query, create, update, and manipulate Salesforce data via Apex and SOQL. Each sObject includes metadata defining fields, data types, and relationships, and supports dynamic field access and polymorphism for reusable, type‑agnostic logic.

How Cloudaware Uses sObjects

Cloudaware, as an ISV managed application on Salesforce, defines a comprehensive set of custom sObjects to represent IT assets, cloud resources, and configuration items discovered from AWS, Azure, Google, VMware, Kubernetes, and other systems. When installed in a customer's Salesforce instance, Cloudaware objects are namespaced (for example, CA10__CaAWSAccount__c), ensuring isolation and version control within the managed package.

• Namespacing: Cloudaware objects and fields are prefixed by a package namespace such as CA10__, CA10K__, CA10TF__ and suffixed by __c (for custom objects and fields).
• CMDB backbone: These objects form the Cloudaware CMDB used by inventory, configuration, compliance, and automation services.
• Ingestion mapping: Cloud discovery pipelines normalize external provider data into Cloudaware sObjects. Downstream automation uses this data for compliance, synchronization, and ticketing.

See also: Force.com and Packages and Field Types

Relationship Types Used in Cloudaware

Salesforce relationships define how records relate across sObjects. Cloudaware uses these relationships to model dependency and hierarchy across IT assets.

• Master‑detail relationship: A strong dependency where the detail record depends on the master record. The detail record inherits ownership and security from the master, and deleting the master also deletes related detail records. Master-detail relationships also support roll-up summary fields on the master. Example: CloudAware Application Tier CA10__CaApplicationTier__c is a detail object related to CloudAware Application CA10__CaApplication__c as the master object through the Application field CA10__application__c.

• Lookup relationship: A flexible association where one record references another record, but both records can exist independently. Lookup relationships are used when the related records should remain separate for ownership, security, or lifecycle purposes. Example: AWS EBS Volume CA10__CaAwsVolume__c looks up to AWS EC2 Instance CA10__CaAwsInstance__c using the Attachment Instance field CA10__attachmentInstance2__c.

• Reference traversal: In SOQL and Apex, use dot notation to traverse child-to-parent relationships. Example: This SOQL query retrieves all EC2 instances that have not been deleted from AWS. CA10__account__c is the relationship field on the EC2 Instance object, and CA10__account__r lets SOQL traverse from the EC2 Instance record to the related AWS Account record and return the account’s Name.

  SELECT Name,
         CA10__account__r.Name,
         CA10__instanceId__c,
         CA10__stateName__c
  FROM CA10__CaAwsInstance__c
  WHERE CA10__disappearanceTime__c = NULL
  ORDER BY Name ASC

Relationship Legend

Term	Description
Master-detail	Strong dependency; child deleted with parent; supports roll-ups
Parent-child	Indicates the navigating reference from child to parent
Lookup	Loose dependency; child remains if parent is deleted (subject to constraints)
Reference	Any field used to traverse to a related record (e.g., Parent__r in SOQL)

Many-to-Many via Junction Objects

Cloudaware uses junction (link) objects to model many‑to‑many relationships between assets, such as associations between AWS EC2 instances and AWS EBS volumes.

• Junction pattern: A custom object with two lookups, each to a different parent. Example: CA10__CaAwsInstanceVolumeLink__c links:
  • AWS EC2 Instance CA10__CaAwsInstance__c
  • AWS EBS Volume CA10__CaAwsVolume__c

This pattern supports compliance checks, reporting, and relationship analysis across linked entities, while accurately modeling complex infrastructure.

Record Types and Relationship Variations

Record types allow different business processes, picklist values, and layouts within the same object. Cloudaware and customers can use record types to extend workflows without modifying the base managed package schema.

• Behavior: A record type (RecordType.DeveloperName) can influence validation, flows, triggers, and UI logic.

• Extensibility: Customers can add record types (where permitted) on Cloudaware objects to distinguish use cases (e.g., on‑prem vs. cloud‑native vs. container workloads) while preserving compatibility with Cloudaware automation and reporting.

• Conditional relationships: Some Cloudaware objects include multiple optional lookup fields to different parents; the active or required relationship may differ by record type. SOQL and Apex should account for this by checking RecordType.DeveloperName or by null-checking lookup fields.
  Example: This SOQL query retrieves all active CrowdStrike vulnerabilities linked to CrowdStrike hosts by filtering by record type:

  SELECT Name,
         CA10CR__crowdstrikeHost__r.Name,
         CA10__caUuid__c
  FROM CA10__CaNessusVulnerability__c
  WHERE CA10__disappearanceTime__c = NULL
    AND RecordType.DeveloperName = 'caCrowdstrikeVulnerability'
    AND CA10CR__crowdstrikeHost__c != NULL
  ORDER BY Id ASC

CloudAware Vulnerability Scan Example

Cloudaware consolidates different scanner findings into a single object (for example, CloudAware Vulnerability Scan CA10__CaNessusVulnerability__c). Record types distinguish sources, and each may use a different primary relationship field specific to the integration.

Record Types and Source Relationships

Record Type Label	Linked Source Object	Description
caCheckmarxOneVulnerability	CA10CO__CheckmarxOneAccount__c	Represents vulnerabilities or findings imported from Checkmarx One; each record is related to the corresponding Checkmarx account in Cloudaware.
caCrowdstrikeVulnerability	CA10CR__CrowdstrikeHost__c	Represents endpoint or vulnerability data discovered via CrowdStrike; linked to the related CrowdStrike Host in Cloudaware.
caGitLabVulnerability	CA10GL__GitLabProject__c	Represents code-scanning or dependency-scanning vulnerabilities originating from GitLab projects.

This approach consolidates findings while allowing distinct compliance and remediation workflows per source.

For more details, see also Vulnerability Scan Record Types.