# mulesoft Cloud Information Model - Full Documentation --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Design Elements > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This guide summarizes the more important design elements that were adopted when defining CIM model objects. ## General Design Elements The following design elements apply to all CIM object definitions. ### Library Organization - The types for each library are defined in separate RAML libraries, one for each entity group. - All types are then published via the main library file for ease of reference. - All types, libraries, and exports are sorted in alphabetical order for quick reference. ### Object Definition - Standard properties such as `id`, `name`, and `description` appear first in each object definition, and in that order. - Objects that include a mandatory `id` property are made nillable to support auto-generated values upon create. - With the exception of strings, optional properties of intrinsic types (such as integer or datetime) are also nillable to support ternary states (set to a value, set to no value, or not present at all). - Since the model is intended to easily extendable as-is, properties with pre-defined enumerations are used very sparingly. - Most entities include an optional set of standard audit properties, usually as the last property defined. - Major entities, which may be synchronized between multiple systems, also include an optional set of external identifier references as the second-last property defined. - Arrays of child objects generally appear near the end of the object definition, typically just before the external identifiers and audit information properties. - To avoid cyclical dependencies, type composition occurs only within a single library file; all references to other entities are defined as string identifiers. - Most type composition is also defined as a union with a string to support flatter message instances where full object hierarchies are not required. - Unions are not used where circular or infinite references are possible (such as a child object referring to the parent). - Types that are intended to be extended always have a discriminator property with the value set to the name of the object. - Child types override the discriminator value to be the name of the child object. ### Object and Property Naming - Boolean properties start with a context-appropriate verb such as `can`, `is`, `has`, `should`, or `was`. - Date/time properties have a suffix corresponding to actual type, such as `DateTime` or `Date` for `datetime` types, and `Time` for `time-only` types - Properties representing internal identifier references to other objects have a suffix of `Id`, except when defined as a union between an identifier string and an actual object - Properties representing coded values end in `Code`. - Properties representing decimal values end in `Number`. - Properties representing arrays have plural names. - Properties used as discriminators end in `Instance`. ## Type Extensions The primary objective of creating CIM type extensions is to re-introduce type composition - in a controlled fashion - to make original core types "whole" for applications that need them. The following rules applied to all core types for which one or more properties had composition removed to reduce external dependencies: - Only types published by the main file for the corresponding subject area library can be extended. - Composition may be re-introduced only for core properties that were originally modified to be strings only (no unions) due to dependencies on external entities. - Composition may NOT be re-introduced where it would create cyclical or infinite references (for example, a reference to self). - All extended type names will be the name of the core parent type suffixed with `Ext` (for example, `ProductExt`). - Similarly, all properties added to extended types will include the suffix `Ext` for clarity and to avoid name collisions (for example, `productTypeExt`). - All properties added to extended types must be made optional. - Extensions may include references to core types defined in other subject areas but NOT extended types. - Similarly, extended type libraries may reference core type libraries but NOT extended type libraries. ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Finance Subject Area > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Activities to trace financial information in the company. For example, payment, invoice and expense report. ## Model Diagrams The following diagrams show the entities and relationships in this subject area, organized by entity group. ### Invoice ![Invoice entity relationships in CIM Finance](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-invoice.png) ### Payment ![Payment entity relationships in CIM Finance](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-payment.png) ### Payment Method ![Payment Method entity relationships in CIM Finance](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-payment-method.png) ## Implementation [CIM Finance Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-finance-library) ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Fulfill Subject Area > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Activities you perform to fulfill an order to a customer. For example, shipment and fulfillment order. ## Model Diagrams The following diagrams show the entities and relationships in this subject area, organized by entity group. ### Fulfillment Order ![Fulfillment Order entity relationships in CIM Fulfill](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-fulfillment-order.png) ### Shipment ![Shipment entity relationships in CIM Fulfill](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-shipment.png) ## Implementation [CIM Fulfill Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-fulfill-library) ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Market Subject Area > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This defines who you have trading relationships with and how. For example, a customer & supplier along with contact information such as phone number and email address. ## Model Diagrams The following diagrams show the entities and relationships in this subject area, organized by entity group. ### Account ![Account entity relationships in CIM Market](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-account.png) ### Contact Point ![Contact Point entity relationships in CIM Market](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-contact-point.png) ### Lead ![Lead entity relationships in CIM Market](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-lead.png) ### Party ![Party entity relationships in CIM Market](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-party.png) ## Implementation [CIM Market Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-market-library) ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Produce Subject Area > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Handling of material that you will be buying, moving and selling. For example, product and inventory product. ## Model Diagrams The following diagrams show the entities and relationships in this subject area, organized by entity group. ### Inventory Product ![Inventory Product entity relationships in CIM Produce](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-inventory-product.png) ### Inventory Received ![Inventory Received entity relationships in CIM Produce](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-inventory-received.png) ### Product ![Product entity relationships in CIM Produce](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-product.png) ### Purchase Order ![Purchase Order entity relationships in CIM Produce](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-purchase-order.png) ## Implementation [CIM Produce Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-produce-library) ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Sell Subject Area > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anything you plan to sell or any part of a product that needs to be tracked for service purposes. For example, you are selling a green tractor. ## Model Diagrams The following diagrams show the entities and relationships in this subject area, organized by entity group. ### Contract ![Contract entity relationships in CIM Sell](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-contract.png) ### Opportunity ![Opportunity entity relationships in CIM Sell](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-opportunity.png) ### Price Book ![Price Book entity relationships in CIM Sell](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-price-book.png) ### Sales Order ![Sales Order entity relationships in CIM Sell](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-sales-order.png) ## Implementation [CIM Sell Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-sell-library) ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Setup Subject Area > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Defines technical resources such as software components and document images. ## Model diagrams The following diagrams show the entities and relationships in this subject area, organized by entity group. ### Generated Document ![Generated Document entity relationships in CIM Setup](/mulesoft/current/en-us/accelerators-cim/latest/_images/accel-cim-generated-document.png) ## Implementation [CIM Setup Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-setup-library) ## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Subject Areas > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The model content is organized into domains, or Subject Areas, which represent major business concepts. Each Subject Area defines one or more Entity Groups, which in turn consist of a related collection of Entities. Each Entity has a set of Attributes defining the unique characteristics of the Entity. ## Supported Subject Areas CIM supports the following subject areas, each of which includes an Entity Relationship Diagram (ERD). See [Diagram Conventions](#diagram_conventions) for the conventions used in the diagrams.
NameDescription

Finance

Entities related to finances, such as payments and payment methods.

Fulfill

Entities related to the fulfillment of goods and services, such as shipments.

Market

Entities related to the marketing and promotion of goods and services, such as individuals, customers, and suppliers.

Produce

Entities related to actual goods and services, such as products and catalogs.

Sell

Entities related to the selling of goods and services, such as sales orders and channels.

Setup

Entities related to technical resources and artifacts.

## Diagram Conventions The diagrams included in each subject group show the entities and relationships defined within that group. Relationships to entities defined in other subject areas are also provided for context. The following table summarizes the conventions used to indicate the status of each entity.
SymbolEntity StatusDescription

Defined Group Entity

An entity in the current group that has a concrete definition.

Undefined Group Entity

An entity belonging to the current group that does not have a concrete definition.

Defined External Entity

An entity defined in a different entity group or subject area.

Undefined External Entity

An entity belonging to a different group or subject area that has not been defined.

## See Also - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # CIM Usage Guidelines > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This document provides some detailed information about how the Cloud Information Model (CIM) is typically used within MuleSoft Accelerators. The primary audience for this document includes architects, consultants, developers, and testers involved in the design, development, and testing of API-based solutions. ## Interpretation of Identifier Properties For all accelerator use cases involving the synchronization of entities between multiple systems (for example, customer profiles), the Global Data System APIs are responsible for generating and maintaining universal identifiers for all entities. Also known as "global" identifiers, these values represent a single, globally unique ID for any given instance of an entity. These values are typically assigned to the `id` property of any given CIM object (for example, `Customer.id`) in all Process APIs, where the representation of the object is expected to be the "golden copy" of it. All other system identifiers are treated as external, and thus may be found in the `externalIds` property where needed. For System APIs, however, the `id` property of any given CIM object will be set to the identifier **understood by that system** on all request/response messages. If supported, the universal identifier will be found in the `externalIds` property with an external ID type of "GLOBAL" or "MDM". The intent behind this approach is to keep the interpretation of the identifiers for a target system as being from the perspective of that system, rather than from the Global Data repository. The same applies to most Experience APIs as well. The following table describes a series of API calls involving a customer profile update published from Salesforce, where the customer exists in the Global Data repository but does not yet exist in SAP, to help clarify identifier usage.
APIMessageObject ID TypeExternal ID Type

Salesforce Experience API

Customer Update

SALESFORCE_CORE

MDM

Customers Process API

Customer Upsert

MDM

SALESFORCE_CORE

Global Data Party System API

Customer Update

MDM

SALESFORCE_CORE

SAP ECC Customers System API

Customer Create

SAP_ECC

MDM

In this example, the Salesforce Experience API expects the value of the incoming `Customer.id` property to be of type `SALESFORCE_CORE`. For an existing customer, the request should also contain an external ID of type `MDM`, which is the global identifier for this profile. To call the Customers Process API, the `Customer.id` value must be set to the Global Party identifier while the original Salesforce identifier is mapped as an external ID. The Process API can use same value for updating Global Data, because the Global Party System API expects the global identifier as input. To create a new profile in SAP ECC, however, the Process API provides the Global Party identifier as an external ID because the SAP System API would expect an SAP identifier (since we are creating a new profile in this case, the `Customer.id` value would actually be set to null in the request). ## Enumerations In CIM, most enumerations are defined as plain strings instead of static enumerations or as complex types (for more normalized structures). We support two distinct types of enumerations: those used as discriminators for polymorphism, and those that represent a coded value from a static list. For discriminators, such as the `partyInstance` property of the `Party` type, the values for these will contain the actual type name (for example, `Individual`). As new child types extending a given base type added, the list of values for that discriminator property will grow. For properties, such as `partyStatus`, on the other hand, the list of values would generally be static and usually pre-defined. Since static value lists often differ from organization to organization (or even between applications), however, most have been defined as simple strings rather then actual enums. This approach also makes the model more flexible when the list may change over time, such as a property that represents an editable picklist in a Salesforce object. ### Enumeration Examples In the following example, `contactPointInstance` is the discriminator property that identifies which type of `ContactPoint` each item in the array of contact points represents, while `ussageType` is the enumeration of `Home`, `Work`, and `Other`. ```json { "contactPoints": [ { "id": "bbafefc5-8cb4-11eb-b4c8-0233bdd64096", "contactPointInstance": "ContactPointEmail", "emailAddress": "traisley@example.com", "usageType": "Home" }, { "id": "15d341df-06da-4fec-a640-29941a6e2bc3", "contactPointInstance": "ContactPointPhone", "telephoneNumber": "8885551234", "usageType": "Work" } ] } ``` ### Predefined Enumeration List The following table identifies all fields that have predefined enumerations used in various accelerator use cases, along with the current list of allowable values.
TypePropertyAllowable values

ExternalId

externalIdType

DOCUSIGN, EDI_SENDER_CODE, LOS, JIRA, OFBIZ, MDM, PIM, SALESFORCE_B2C, SALESFORCE_CORE, SALESFORCE_FSC_BANKING, SALESFORCE_FSC_INSURANCE, SALESFORCE_FSC_WEALTH, SALESFORCE_MARKETING, SALESFORCE_SALES, SALESFORCE_SERVICE, SAP_ECC, SAP_4HANA, SERVICENOW

status

VALID, INVALID

Customer

customerStatus

ACTIVE, INACTIVE

PartyRelatedParty

partyRelationshipType

AGENT, BUYER, CHILD, CLIENT, OTHER, RELATION, SPONSOR, SPOUSE, SUPPLIER, USER, VENDOR

Product

type

MASTER, VARIANT

SalesOrder

salesOrderType

ADD_ON, CANCELLATION, INITIAL, JOURNAL, RENEWAL, RETURN, SUBSCRIPTION, UPGRADE

salesOrderStatus

CANCELLED, CREATED, CONFIRMED, DELIVERED, IN_CART, IN_TRANSIT, INVOICED, LOST, PARTIALLY_SHIPPED, PICKUP_AVAILABLE, PROCESSING, REJECTED, RETURNED

SalesOrderProduct

salesOrderProductStatus

ACTIVE, DISCONTINUED, INACTIVE, NOT_SELLING, OUT_OF_STOCK

## Composition In the first version of the CIM libraries created for use by Accelerator assets, objects were structured to support a great deal of flexibility when it comes to composition. Put simply, applications had the ability to represent entities either as flat structures, where references to other entities are provided as strings, or as tree structures, where child or referenced entities are embedded as part of other objects. In the current version of CIM, the number of cases where this is supported has been significantly reduced. In fact, it is only supported - and in limited fashion - within the individual libraries of related types of an entity group. ### Composition Example For example, a flat representation of an Individual instance might look like this, where only key references to the associated contact points are provided: ```json { "partyInstance": "Individual", "personName": "Scott Jenks", "firstName": "Scott", "lastName": "Jenks", "contactPoints": ["1ea2d3bd-8cb0-11eb-b4c8-0233bdd64096", "1defef22-8cb0-11eb-b4c8-0233bdd64096"] } ``` The same definition of the model also supports a more complete representation of the Individual, however, by allowing complete ContactPoint objects to be provided: ```json { "partyInstance": "Individual", "personName": "Scott Jenks", "firstName": "Scott", "lastName": "Jenks", "contactPoints": [ { "id": "1ea2d3bd-8cb0-11eb-b4c8-0233bdd64096", "contactPointInstance": "ContactPointPhone", "telephoneNumber": "551-488-6996" "formattedNationalPhoneNumber": "(551)488-6996", "activeFromDate": "2015-03-15", }, { "id": "1defef22-8cb0-11eb-b4c8-0233bdd64096", "contactPointInstance": "ContactPointEmail", "emailAddress": "Jenks.Scott@example.com" "activeFromDate": "2015-03-15", } ] } ``` Individual applications may therefore choose to support arbitrary levels of composition in API requests and responses while still remaining valid against the model definition. This approach also allows object hierarchies to be constructed from a flat set of arrays. ## See Also - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Overview](https://docs.mulesoft.com/accelerators-cim/latest/) --- product: Cloud Information Model version: 2.0 is-latest-version: true --- # Cloud Information Model for MuleSoft Accelerators > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The use of good, comprehensive canonical data models in API specifications is key for maximizing the reuse and flexibility of the interfaces and limiting the amount of data transformation logic required between the Experience, Process, and System layer in an API-led approach. Many organizations struggle with this, however, often ending up with disparate object definitions for the same entities across different APIs. This leads to brittle and often complex data transformations, which become difficult to maintain over time. The Cloud Information Model (CIM) for MuleSoft Accelerators is an application-agnostic data model that simplifies integration and accelerates innovation. The use of CIM as a canonical model reduces barriers to cross-product integration and extends the value proposition of our solutions by exposing a common model across our Process and System APIs. With CIM, you can create seamless and tailored personal experiences across cloud-native applications. ## History of CIM Inspired by the [Salesforce Customer 360 Data Model](https://help.salesforce.com/s/articleView?id=sf.c360_a_c360datamodel.htm&type=5), CIM was created to deliver a standards-based solution for connecting enterprise products. The original distribution of CIM was produced by an open consortium, which was formed to deliver a standards-based solution for connecting enterprise products. Although it was adopted by MuleSoft for use in various accelerators, limited adoption by other companies led to the consortium being halted and the primary website was archived. The version of CIM created and maintained by the MuleSoft Solutions team is now known as the Cloud Information Model for MuleSoft Accelerators. Release 2.0 of the model represents a significant upgrade and enhancement of virtually all object definitions, with simplified structures, additional inline documentation, and improved examples. ## Organization The model content is organized into domains, or Subject Areas, which represent major business concepts. Each Subject Area defines one or more Entity Groups, which in turn consist of a related collection of Entities. Each Entity has a set of Attributes, which define the unique characteristics of the Entity. Refer to the [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) page for the list of subject areas that are currently supported. ## Implementation The version of CIM used by the MuleSoft Accelerators is represented as a set of RAML library fragments. There is a core library for each subject area, plus vertical extension libraries that may introduce additional types, or aggregate types from the core libraries, for better alignment with certain industries. Each library provides a set of examples along with a set of JSON schema definitions for each object, which can be useful for defining metadata types when developing applications in Anypoint Studio or for schema validation of messages. Refer to the [Accelerator CIM Global Library](https://anypoint.mulesoft.com/exchange/org.mule.examples/accelerator-cim-global-library) home page to get started with using the model. ## See Also - [CIM Design Elements](https://docs.mulesoft.com/accelerators-cim/latest/cim-design-elements) - [CIM Usage Guide](https://docs.mulesoft.com/accelerators-cim/latest/cim-usage-guide) - [CIM Subject Areas](https://docs.mulesoft.com/accelerators-cim/latest/cim-subject-areas) - [Getting Started Guide](https://docs.mulesoft.com/accelerators-home/getting-started)