Salesforce Revenue Cloud : Consuming Context Definitions from Apex Code

1. Introduction

Salesforce Revenue Cloud has become the platform of choice for managing complex quote-to-cash processes. With capabilities like Product Catalogs, CPQ, Contracts, Billing, and Advanced Approvals, it helps organizations streamline every stage of the revenue lifecycle.

Behind the scenes, many of these capabilities rely on Context Definitions—a structured way of defining and passing contextual information across Revenue Cloud services. For developers and architects building on top of Revenue Cloud, learning how to consume Context Definitions in Apex is an essential skill.

In this post, we’ll cover what Context Definitions are, why they matter, and walk through an end-to-end example of hydrating and consuming them using Apex. By the end, you’ll know how to apply this knowledge in your own orgs—whether for pricing, rules, or data enrichment.

Prerequisite: Familiarity with Context Service Basics.

2. What Is a Context Definition?

A Context Definition is a metadata-driven structure used to pass data into Revenue Cloud services in a consistent and reusable way. It is defined by a set of core building blocks -

1. Nodes – Containers for attributes mapped to Salesforce objects. Each node can hold multiple attributes.

2. Attributes – Containers for data, mapped directly to fields on an object.

3. Context Tags – Simple aliases for nodes and attributes, used by consuming applications to query context data easily.

4. Context Mappings – The link between nodes/attributes and input data sources. A single context definition can support multiple mappings to serve different use cases.

A context definition typically follows four stages:

1. Creation (Design time) – Defining nodes, attributes, tags, and mappings.

2. Hydration – Populating the definition with actual record data at runtime.

3. Consumption – Querying or transforming hydrated data.

4. Persistence – Writing any changes back into mapped objects.

3. Context Service APIs

The Context Service provides a set of Apex APIs to interact with context definitions. In this post, we’ll focus on hydration, retrieval, and querying.

• Build: Load data into a context.

  • buildContext – Create a context instance at runtime.

  • getContext – Retrieve details of an existing context.

  • deleteContext – Delete a context instance.

• Query: Explore data within the context.

  • queryContextRecordsAndChildren – Retrieve records and child records.

  • queryTags – Retrieve tag values.

• Update: Modify an existing context.

  • updateContextAttributes – Update data in the context.

  • addRecordToContext – Add new data.

• Persist: Save context data back to the database.

  • persistContext – Write hydrated context data to mapped objects.

4. Applications of Context Definitions

Context Definitions appear in many Revenue Cloud scenarios, including :

• Pricing Procedures – Passing quote and product information into the pricing engine.

• Product Discovery – Determining which products or services are eligible for a customer.

• Contracts & Assets – Handling renewals, asset-based ordering, and related conditions.

5. Consuming Context Definitions from Apex

From a developer’s perspective, consuming a Context Definition directly in Apex is useful when:

• Triggering Apex hooks within a procedure plan.

• Testing or validating changes made to a Context Definition.

• Building custom solutions that consume or share a hydrated context.

Instead of writing SOQL queries and reproducing mappings manually, you can rely on the Context Service APIs to tap into hydrated data directly.

6. Apex Sample

7. Tips

Working with Context Definitions in Apex can be tricky. Keep these in mind:

1. You can build a context using either IDs or Developer Names for the definition and mapping..

2. The Context Id (runtime) is not the same as the Context Definition Id (metadata).

3. A context won’t hydrate with data if no mapping exists for a given node.

   1. The SalesTransactionContext definition includes three nodes—SalesTransaction, Asset, and Contract. Since the QuoteEntitiesMapping does not include mappings for Asset or Contract, those nodes will never be hydrated when QuoteEntitiesMapping is applied (Even when you add a record for Asset/Contract - ref: Line 33 in ContextUtilityDemo class).