Force.com & Cloudaware Packages
This guide explains how Cloudaware is delivered as managed packages on Salesforce’s Force.com platform, how the core StackBoard (CA10) package and its extensions are structured, and how to interpret Cloudaware package prefixes and objects when navigating the CMDB and API schema.
Relation to Force.com
Cloudaware is built as a managed application running on Salesforce’s Force.com platform, leveraging its infrastructure, data model, and security framework. Cloudaware operates as a native Force.com app installed directly into a customer’s Salesforce organization (instance) as a package. All functionality — such as CMDB objects, automation, integrations, and dashboards — resides within this Salesforce environment.
Core Package: StackBoard (CA10)
The core Cloudaware package is called StackBoard (CA10). It includes the primary data model and essential components that form the foundation of the Cloudaware CMDB and applications. Cloudaware developers continuously enhance this core package and its related extensions while ensuring compliance with Salesforce’s platform limits and best practices for multi-tenant environments.
Naming Conventions & Identification
Cloudaware packages use a unique CA prefix combined with alphanumeric identifiers (e.g. CA10C, CA10K, CA10TF, etc). The identifier reflects origin and purpose. By referencing a prefix, it’s straightforward to locate all objects associated with a specific integration or cloud platform within the broader Cloudaware sObject dataset.
See also: Naming & Identifiers and Field Types
Extension Packages
Extension packages add additional sObjects for specific cloud providers that do not fit within the core StackBoard package. They use the naming format StackBoard:{cloudName}.
| Package Prefix | Package Name | Object Example |
|---|---|---|
CA10AC | StackBoard: Alibaba Cloud | CA10AC__CaAlibabaCloudAccount__c |
CA10O1 | StackBoard: Oracle Cloud | CA10O1__CaOracleCompartment__c |
Integration Packages
Integration packages include metadata and custom objects that support third‑party integrations, designed for modular, future use. They use the naming format StackBoard:{integrationName}.
| Package Prefix | Package Name | Object Example |
|---|---|---|
CA10C | StackBoard: CyberArk | CA10C__CaCyberarkAccount__c |
CA10K | StackBoard: Kubernetes | CA10K__CaKubernetesCluster__c |
CA10TF | StackBoard: Terraform | CA10TF__CaTerraformOrganization__c |
Managed vs. Custom Objects in Cloudaware
From Salesforce’s perspective, Cloudaware is installed as a managed package. Therefore, all Cloudaware objects appear as custom objects identified by a namespace prefix such as CA10__, CA10K__, CA10TF__, etc. This prefix distinguishes them from standard Salesforce objects and ensures namespace isolation.
From Cloudaware's perspective, objects delivered within Cloudaware‑managed packages are considered managed objects in the Cloudaware data model — maintained, versioned, and updated by Cloudaware developers. Therefore, any additional objects created directly by a customer in their Salesforce organization are considered custom relative to the Cloudaware model, even though Salesforce classifies all Cloudaware objects as “custom” due to the namespace.
See also: Custom Objects
Managed Package Versioning and Delivery
Cloudaware developers continuously improve the core package and its extensions to operate within Salesforce limits across customer orgs. Each package has a version and is delivered to the customer’s Salesforce instance promptly as a managed package release.
List of All Objects
The complete list of Cloudaware package objects can be found via Setup → Object Manager/Objects.
Summary
Cloudaware’s package design enables the platform to expand functionality across cloud and integration ecosystems while maintaining scalability and alignment with Force.com architecture.