You are here:
Dynamic Context Service Invocable Actions
Manage your business application data efficiently by combining the capabilities of Salesforce Flow and Context Service dynamic invocable actions.
Required Editions
| Available in: Lightning Experience |
| Available in: Developer, Enterprise, Professional, and Unlimited editions for Industries clouds where Context Service is enabled |
Dynamic Invocable Actions in Context Service
To use dynamic invocable actions, first generate an Apex class from the context definition.
| Invocable Actions | Description | Input Values | Comment |
|---|---|---|---|
Build Context Instance Dynamically |
Builds a context instance of a context definition with an Apex-defined input. |
Context Record Data (optional): The Apex-defined variable containing the records to build the context instance. Context Mapping ID (optional): The name or ID of the context mapping record used to build the context instance. |
Step 1 (Node Level): Create an Apex-defined variable for the specific node you want to hydrate (e.g., AccountApex of type context_SalesContextDef_Account.apex). Step 2 (Data Setup): Assign the id and businessObjectType to this variable to specify which record to fetch. Step 3 (Root Level): Create a root Apex-defined variable (e.g., ApexIP of type context_SalesContextDef_DefRoot.apex). Step 4 (Linking): Add your node variable (AccountApex) to the root variable’s list (e.g., ApexIP.Account) to establish the hierarchy. Step 5 (Invocation): Pass ApexIP into the Apex-Defined Input parameter of the action. |
Add Context Records Dynamically |
Adds or overwrites records in a context instance with an Apex-defined input. |
Context ID: The ID of the context instance in which to add or overwrite records. Context Record Data: The Apex defined variable containing the records to add to the context instance. Overwrite Existing Records (Optional): Indicates whether to overwrite existing records. Default is False. |
Build the hierarchy manually in the flow using assignments before calling the action. Parent-Child linking: If adding a child node Opportunity to an existing parent node Contact, you must create an Opportunity Apex variable, then create a Contact Apex variable, assign the existing Contact's ID to it, and then ADD the Opportunity variable to the Contact's child list. Add the entire nested structure to the DefRoot variable before passing as the Apex Defined Input. |
Query Context Records Dynamically |
Queries records in an existing context instance with an Apex-defined output. |
Context ID: The ID of the context instance to query. Query Paths: A collection of data paths to the records to be queried. Context Mapping ID (optional): The name or ID of the context mapping record used to build the context instance. |
Defining Paths: You must create a List of Strings variable (QueryPaths). Path Syntax: Manually add strings that follow the hierarchical relationship separated by forward slashes, such as AccountId/ContactId/OpportunityId. Handling Results: Manually assign the output to an Apex-defined variable of the root type. Querying a parent node returns its direct children within the same Apex object. |
Update Context Record Dynamically |
Updates the context attributes from an instance of a context definition with an Apex-defined input. |
Context ID: The ID of the context instance in which you want to update attributes. Context Record Data: The Apex-defined variable containing the context definition records to be updated. |
Specific Record Identification: You must populate the dataPath parameter within your node-level Apex variable to tell the service exactly which record in the cache to update. Assignment: Assign the new values to the attributes (e.g., accountApex.billingcity = 'Bangalore'). Linking to Root: Add this updated node variable to your SalesRootApex collection. Invocation: Pass the root variable into the Apex-Defined Input Object. |
Query Tags |
Queries the dynamic context tags from a context instance of a context definition with a related Apex-defined output. |
Context ID: The ID of the context instance to query. Tag List: A collection of tags to be queried. |
Step 1 (Output Variable): You must define a flow variable of type Apex-Defined and specifically select the generated root class (e.g., SalesContextDef_DefRoot). Step 2 (Manual Assignment): In the action's "Advanced" section, manually assign the Query Result to that variable. Step 3 (Reading Data): To access data, you must loop through the collection inside the root object (e.g., apexOutput > Opportunity) because individual node references are always returned as collections. Note: Access values using the attribute names, not the context tags. |
Input Strategy for Build Context and Add Records
To link related objects, you must establish the parent-child relationship within the Apex variables before passing the root object to the invocable action.
For example, for linking a child node Contact to a parent node Account:
- Create an Apex-defined variable for the child node (e.g., ContactApex) and the parent node (e.g., AccountApex).
- Assign values to the ContactApex attributes (e.g., LastName, id).
- In the Flow, use an Assignment element to add ContactApex to the AccountApex.Contact collection.
- Add the AccountApex to the main root variable (e.g., ApexIP.Account).
- Pass the completed root variable (ApexIP) into the Context Record Data parameter of the action.
Output Strategy for Query Tags
- When querying tags, a populated instance of the root Apex class is returned.
- Even if a node is deeply nested (e.g., Opportunity under Contact under Account), you can often refer to the collection directly from the root class (e.g., SalesContextDef_DefRoot.Opportunity).
- Because node references in the generated Apex are always returned as Collections (Lists), you must use a Loop element in Flow to access individual attributes, even if you expect only one record.
- In the Flow loop, access data using the Apex attribute names (e.g., item.BillingCity), not the Context Tag names, because tags are not available in the Apex class.
