Context Service is a shared platform capability used across multiple Salesforce Industries clouds, not just Agentforce Revenue Management (ARM).
Across these clouds, the same handful of data (price, product, region, quantity, and more) is often needed in a dozen different places. Context Service is the layer that hands that data over consistently, no matter which record it actually lives on.
In short, Context Service simplifies how transactional data is retrieved, stored, and transformed.
The Problem Before Context Service
Pricing, eligibility, promotions, and AI agents all need the same core facts about a transaction. Without a layer in between, each of them has to know exactly where those facts live, and that gets messy fast.
With direct connections, every process is wired straight to every object: pricing, eligibility, and promotions each reach into the Quote, the Order, and the Asset. If you change one field on the Order, you have to find every process that used it directly.
With one shared layer, every process asks Context Service, and Context Service asks the data. If you change one field on the Order, you update one mapping, and every process above it keeps working.
Imagine life without Context Service. How would you pass data along as the transaction moves forward? You'd probably reach for a Flow Get Records action or SOQL. With Context Service, you don't need to.
You could still build it that way, with a Flow query action or SOQL for each field and each object pair. But that kind of custom relay is exactly what Context Service exists to replace. Salesforce's own explanation for the service is that developers used to write custom integration code for every data source they touched, and every extra step in a process meant another trip to the database.
Context Service also reflects Salesforce's API-first approach, in which a feature receives a solid API before anyone designs a UI for it. There's no dedicated screen where you "use" Context Service. Instead of writing custom code to access a Quote, Order, or Asset every time a process needs a value, you call an existing API via REST, Apex, or a Flow action. It returns the data in the same standard format regardless of which record it came from. Context Service puts all that access into a small number of mappings, rather than a growing pile of point-to-point automations that can each quietly break when a field is renamed.
What it really saves is maintenance. The same relationship between two fields is defined in fewer places, so there are fewer things to find and fix when one of them changes.
A Real Example: Pricing a Quote
A rep saves a quote. The transaction type is Pricing, so Context Service loads the Pricing Context Definition. Here's what happens at each layer.
1. Application layer (the Salesforce Quote page). A rep builds a quote and saves it. The page knows which record it is and what the rep wants, which is to price it. It knows nothing about how the price is calculated. The pieces involved are the Quote, the quote lines, and the LWC quote line editor.
2. Transport (the platform invocation). This is the call itself: a Flow, Apex, or an API request that carries the transaction to the service. It moves the data along and doesn't keep any of it. Examples are a pricing procedure step, an invocable action, or a REST call.
3. Context Service (the Context Definition for Pricing). It reads the transaction type, picks the definition registered for Pricing, and turns that definition's structure of nodes into a Context Instance. Context Service decides the shape of the data and where each piece comes from, but it isn't the place where the data is stored. The Pricing definition includes nodes for the quote, its lines, the product, and the price book.
4. Data source (the mapped objects). These are the records each node is mapped to: Quote, QuoteLineItem, Product2, PricebookEntry, and Account. The Context Instance is a view built on top of them. If you deleted the definition, the data would still be there.
Finally, the priced lines return to the quote page.
How Context Service works
Think of it as three layers. Applications sit at the top: Pricing, Eligibility, Promotions, and Agentforce. Context Service sits in the middle as the go-between. The data sources are listed at the bottom: Quote, Order, Asset, custom, and DMO objects. Every request goes down through the same three layers, and every answer comes back up through them.
Reading data: A process sends a request down through Context Service. Context Service checks the mapping, fetches the actual field values, and returns a clean, standard answer. The process never directly touches the underlying object.
Writing data: When a process updates data, it writes to the temporary copy held in memory. Context Service then saves that change back to the correct field on the correct record.
The building blocks of a Context Definition
Everything in Context Service is built from a Context Definition.
Context Definition. This is the overall blueprint for one process. It bundles all Nodes, Attributes, Tags, and Mappings the process needs into a single reusable package. Salesforce ships ready-made Standard definitions for common processes. You can Extend one to add your own pieces without touching the original and to have yours updated with new out of box nodes and attributes on new releases, or Clone one if you also need to change the parts it came with, though you will need to manually add in new out of box nodes and attributes when a new release hits.
Node. A node represents one business entity, such as the transaction itself or a single line item. Nodes can sit inside each other to show how the entities relate. This is how Context Service gives pricing a consistent shape to read, whether the real record underneath is a Quote or an Order. Example: SalesTransaction represents a Quote or an Order. SalesTransactionItem sits inside it and represents one line in the deal, meaning a Quote Line or an Order Item.
Attribute. An attribute is one specific piece of data inside a node, such as unit price, quantity, or region. Each attribute has a data type (text, number, currency, or date) and a direction: Input (the value flows in), Output (the value flows out), or both. Example: a Unit Price attribute on SalesTransactionItem might read from QuoteLineItem.UnitPrice in one mapping and from OrderItem.SalesPrice in another. It's the same attribute pointing at a different real field, depending on which mapping is active.
Tag. A tag is a short nickname a process uses to ask for a node or attribute without knowing where it actually lives. Tags are unique within a definition, and they're what a process actually requests while it runs. If the underlying mapping changes later, nothing downstream has to be rewritten. Example: pricing logic asks for the tag "UnitPrice" directly. Whether that points to a Quote Line field or an Order Item field doesn't matter to it.
One lifecycle, several definitions
Different stages of a transaction's lifecycle use different Context Definitions, rather than one giant definition that tries to cover everything. Salesforce ships standard definitions for the stages you'd expect:
Product Discovery for configuring what's being bought
SalesTransactionContext for pricing and quoting once a Quote or Order exists
Asset for tracking what has actually been sold after the deal closes
Contract for contract lifecycle management
Document Generation for pulling context data into documents like contracts, with dynamic content and logos
These aren't completely separate, either. A Context Definition can reference another Context Definition directly. The Association mapping intent (covered below) is what connects them. For example, it can link a SalesTransaction node to an Asset node, so that pricing logic and asset-lifecycle logic each operate on their own definitions but can still reference each other's records when needed.
In practice, you rarely build a Context Definition entirely from scratch. Your org's transaction lifecycle usually fits one of the existing standard definitions already. The real decision is which one to Extend or Clone, and how, rather than inventing a new structure for something Salesforce has probably already modeled.
Context Mapping: Connecting the blueprint to real data
A Context Definition only describes a shape: its nodes, attributes, and tags. It isn't connected to any data source yet. Mapping is the separate step that does that. You match each node to a Salesforce object, then each attribute to a specific field on that object.
Because mapping is separate from the definition, one shape can have multiple mappings side by side, such as one pointed at Quote and another at Order, without changing the nodes or attributes at all.
For every field a mapping touches, the Mapping Intent determines what's allowed to happen to it: it can be read-only, written back, transformed along the way, or simply linked. There are four options.
Hydration (read only). This loads a value into the Context Instance for reading only. The process can see it, but nothing is ever written back to the source record. Use it whenever a process just needs to know a value, not change it. Example: pulling in a Quote Line's current Unit Price so pricing logic can evaluate a discount, without changing the Quote itself.
Persistence (write back). This saves a value from the Context Instance back onto the real record once processing finishes. If Persistence isn't set on a field, any change made inside the instance is lost as soon as the instance is discarded. Example: writing a newly calculated discount amount back onto the Quote Line so the sales rep sees the updated price.
Translation (transformed). This changes a value as it moves from one context to another. Use it whenever the source and target don't match up as a simple one-to-one copy, whether that's because of a different field, a different data type, or a different unit. Example: converting a Quote's one-time discount percentage into a flat adjustment amount on the Order during Quote-to-Order conversion.
Association (linked, not moved). This keeps a reference between records, for navigation or custom logic, without copying any data. Use it when a process only needs to know that two records are related, not what's on either one. Example: linking a Context Instance back to its source Quote Id so a custom Flow can look it up later, without pulling any of the Quote's fields into the mapping.
Tip: Some fields go both ways: they're read in now and saved later, like a calculated discount. These need both Hydration and Persistence set on the same mapping.
Context Instance: A temporary snapshot
Every time a process runs, Context Service builds a fresh, temporary copy of just the data that the transaction needs, then lets it go.
Build. A process opens a Quote. Context Service builds a Context Instance in memory, using the mapping to pull in exactly the fields the definition asks for.
Use. Pricing, eligibility, or promotions read and update that instance. This is fast because everything is in memory, with no round trips to the database.
Save or discard. Changed values that have Persistence set are saved to the real record. Everything else in the instance disappears once the process finishes or its time limit (TTL) runs out.
Context Service in Salesforce Pricing
Salesforce's pricing engine doesn't want to care whether it's looking at a Quote or an Order, so it only ever looks at two standard shapes:
SalesTransaction is the header. It captures deal-level facts from whatever the source record is: Account, currency, and transaction date.
SalesTransactionItem is the line. There's one per product or line item, holding unit price, quantity, region, and discount.
Whether the data starts as a Quote or an Order, the pricing engine runs the same logic every time.
Let's See It In Action
Veni walks through a Context Service demo using a real-world scenario.
Picture a group of friends checking out together on one shared Quote. Each of them has their own Rewards Card and wants to redeem their points against just the item they're buying. The Quote belongs to the whole group, but the rewards belong to each person, so I need a way to carry customer-specific data at the line level, all the way from Quote to Order.
A Few More Tips
Here are a few more concepts to keep in mind as you move from reading about Context Service to setting it up.
Standard, extended, and cloned definitions
You rarely start from a blank page. Salesforce ships standard definitions for common processes. They're read-only, but they're a solid starting point. You have four options:
Extend a standard definition to add your own nodes and attributes on top. When Salesforce updates the standard parts, your extension gets those updates automatically.
Clone a definition when you need to change the parts it came with. Clones don't update automatically, so you have to keep them in sync by hand.
Start from scratch when nothing standard fits.
Transposable nodes (key-value data)
Sometimes you don't know in advance how many attributes something will have, such as a product's custom attributes like color, size, and material. Marking a node Transposable lets it store open-ended key-value pairs instead of a fixed list of attributes. One attribute holds the key (for example, "Color") and another holds the value (for example, "Blue"). This option is only available on custom nodes.
Request-scoped vs. session-scoped instances
A request-scoped instance exists only for as long as the single Apex call, API request, or Flow that created it. A session-scoped instance lasts longer, up to its TTL (Time To Live). The TTL is 10 minutes by default, and for custom, extended, or cloned definitions you can raise it to a maximum of 45 minutes.
The four API actions
Developers use these behind the scenes. You don't need the syntax, just what each one is for:
Build: create (or delete) a Context Instance.
Query: read records or tag values from a running instance.
Update: change or add data inside the instance.
Persist: write the instance's current data back to the database.
Common mapping mistakes to avoid
Setting Persistence on a field that only ever needs to be read. This adds unnecessary risk of writing bad data.
Mapping straight to Quote or other sales object fields instead of going through SalesTransaction. That defeats the purpose of having a shared shape.
Forgetting Translation when a Quote becomes an Order, so values don't carry over correctly.
Using Association as a shortcut to copy data. It's for linking records, not for moving values.
Glossary
Context Service: The layer that standardizes how applications request and update transaction data, regardless of where it's actually stored.
Context Definition: The blueprint, meaning the full set of nodes, attributes, tags, and mappings one process needs.
Node: A section of the blueprint that represents one business entity, such as the transaction itself or a single line item.
Attribute: A single piece of data inside a node, with a set data type.
Context Tag: A short nickname a process uses to fetch a node or attribute without knowing which field it actually comes from.
Context Mapping: The connection between the blueprint and real fields on real objects.
Mapping Intent: What's allowed to happen to a mapped field: Hydration (read), Persistence (write), Translation (transform), or Association (link only).
Context Instance: A temporary snapshot of data held in memory, built fresh for one transaction and then either saved or discarded.
SalesTransaction: The standard header-level shape the pricing engine reads. There's one per Quote or Order.
SalesTransactionItem: The standard line-level shape the pricing engine reads. There's one per Quote Line or Order Item.
TTL: Time To Live, meaning how long a session-scoped Context Instance stays available (10 minutes by default, 45 minutes at most).
Key takeaways
Context Service separates business data from the specific Salesforce objects it happens to be stored on.
SalesTransaction and SalesTransactionItem always give the pricing engine the same shape to work with.
The four Mapping Intents (Hydration, Persistence, Translation, and Association) control exactly how each field is allowed to move.
The result is pricing, eligibility, and AI logic you can reuse, which keeps working when the underlying data model changes.
What's next
Context Service often flies under the radar until you are left maintaining a Revenue Cloud architecture bogged down by custom connections. Whether you are architecting a new Revenue Cloud implementation or untangling an existing one, evaluating Context Service early can drastically reduce ongoing technical debt.
About the author
Veni Gonzales is a Senior Salesforce Developer at Stratus Carta, based in Pasig City, Philippines. Veni holds 11 Salesforce certifications, has four years of hands-on Salesforce experience, and now focuses on Revenue Cloud implementations.
Before working in Salesforce, Veni spent 13 years in telecommunications, in billing operations, application support, and environment management. That background brings a practical perspective to Revenue Cloud work. Veni has seen the operational side of quote-to-cash firsthand and knows what happens downstream when transaction data is inconsistent or hard to maintain.
Connect with Stratus Carta
Don't let custom connections slow down your Revenue Cloud roadmap. Schedule a Revenue Cloud architecture review with our team today. Reach out to us on LinkedIn.
