Dynamic Revenue Orchestrator Additional Information
This Page
All Documentation
Get to know additional deployment information for Dynamic Revenue Orchestrator (DRO) in Revenue Management, including active or inactive states, object information, and migration considerations.
RuleSet API Naming Pattern
In API version 67.0 and later, RuleSet API naming is decoupled from the parent record ID and uses a global key (UUID). This naming pattern removes the pre-commit dependency on record IDs and enables condition JSON processing during INSERT operation for records.
Existing RuleSet records that use the legacy record ID-based naming patterns keep their original API naming pattern and aren’t automatically renamed. Legacy and current naming patterns can coexist in the same org. No mandatory migration is required solely to normalize RuleSet API names.
Special Fields
These objects use a large text field to contain a JSON representation of Dynamic Revenue Orchestrator (DRO) condition data, backed up by internal Business Rules Engine (BRE) RuleSet objects.
FulfillmentStepDefinition
ExecuteOnConditionData. This is related to ExecuteOnRule field (RuleSet reference).
ResumeOnConditionData. This is related to ResumeOnRule field (RuleSet reference).
ProductFulfillmentScenario
ConditionData. This is related to ScenarioRule field (RuleSet reference).
ProductFulfillmentDecompRule
ConditionData. This is related to ExecuteOnRule field (RuleSet reference).
FulfillmentTaskAssignmentRule
ConditionData. This is related to Condition field (RuleSet reference).
Condition JSON fields support full lifecycle behavior for global key-based naming pattern records. You can provide condition JSON at insert, modify it through updates, and remove it to delete associated RuleSet artifacts where applicable. Here are the details for each operation type.
You can create the record and provide condition JSON in the same transaction, including bulk operations.
When you change condition JSON, the related RuleSet reference and runtime evaluation logic are updated.
When you remove condition JSON, the related RuleSet artifacts are deleted where applicable, including resume on rule scenarios.
After migration, refresh the related Decision Tables.
Orchestration Plan Context Mapping
OrchestrationPlanCtxMapping
This setup object is always active after creation. Here are some considerations. The object must have an active context definition to create the mapping, The context definition must remain active for the mapping to be valid, or Context nodes or referenced mappings must exist in the active context definition version.
Context rules library is Active with Usage Type=Dfo and is linked with Sales Context Definition.
The active rule library version must point to the context definition currently configured in the DRO Admin settings. If you change the context definition in the settings, you must create a new rule library version that links to the new definition and activate it.
When creating a version, you must clone from the latest rule library version. If you clone from an older version instead of the latest, any rule sets created in the latest version is lost in any other newly created version. This leads to evaluation errors where rules evaluate to false as the engine is unable to find the rule set in the active library.
When moving to a new version, you must first deactivate the older version and then activate the cloned version.
Context definitions must have the necessary nodes, mappings, and context tags used in rule sets.
DRO rules include Product Fulfillment Decomposition Rule, Fulfillment Step Definition, Product Fulfillment Scenario, and Fulfillment Task Assignment Rule objects. To migrate DRO rules or scenarios, make sure the AttributeDefinition and AttributePicklistValue records are referenced in condition data fields by attribute code and picklist value name in the org before migration. The code value is defined in product management records.
The SourceAttributeIdentifier and DestinationAttributeIdentifier fields of a ProductDecompEnrichmentRule record can include attribute IDs from the source org, leading to invalid references in the target org. Refresh the identifier fields by saving the ProductDecompEnrichmentRule records again. You can also set the identifier fields to null during migration to make sure that they auto-populate correctly.
Before you can migrate the Product Fulfillment Decomposition Rule, Fulfillment Step Definition, Product Fulfillment Scenario, and Fulfillment Task Assignment Rule objects with their related child records, several other key records must exist in the target Salesforce org. Migrating these records first is crucial to maintain data integrity and to make sure that the relationships are correctly established in rules.
Here are the required records in the target org as per the required migration sequence.
Products (Product2)—The top-level ProductFulfillmentDecompRule record is directly linked to a specific product via the ProductId field. You can’t create the rule without associating it with an existing product record.
Make sure that the Product2 records in the source and target orgs can be uniquely identified. For example, use a custom external ID field such as GlobalKey__c or any other ExternalId field, or use the standard ProductCode field.
Attribute Definitions (AttributeDefinition)—The ProductDecompEnrichmentRule records, which are children of the decomposition rule, use attribute definitions to specify which product attributes to use for enrichment or transformation. These rules reference AttributeDefinition records in fields, such as SourceAttributeDefinitionId and TargetAttributeDefinitionId. DRO Condition Data fields and rule sets use AttributeCode values in Condition Expressions.
Attribute Definitions must be migrated before the enrichment rules to make sure that the lookup relationships are resolved successfully. Attribute Code values must be defined as these values are used in DRO Conditions as unique identifiers for attribute-type expressions.
Attribute Definition Picklist Values (AttributePicklistValue)—The ValTfrm (Value Transform) records, which are used for mapping and transforming data, often rely on picklist values defined in the AttributePicklistValue object. These records define the specific values used in the transformation logic. DRO Condition Data fields and rule sets use AttributeCode values in Condition Expressions.
If your transformation rules involve picklist fields, you must migrate the corresponding AttributePicklistValue records first.
DRO Rules and Scenario Migration
Internal rule set tables may contain attribute ID values, which are the Salesforce IDs of the relevant AttributeDefinition records of the Product or Product Classification.
DRO stores rule set-related data in string representation with AttributeDefinition. During migration, the JSON representation of a rule set uses Attribute Code as the natural key to resolve AttributeDefinition records and set as key in internal rule set tables. As a prerequisite, make sure that attribute code values are populated and consistent in both the source and target orgs before you migrate DRO rules.
Rule sets also contain attribute picklist values in condition expressions. The AttributePicklistValue records of the associated AttributeDefinition records must exist in target org before you migrate DRO rules.
In API version 67.0 and later, you can insert DRO rule and scenario records with condition JSON in one transaction, including bulk inserts, when prerequisites are satisfied.
Deleting a DRO parent record also deletes related RuleSet and rule artifacts to prevent orphan records. If condition JSON is removed from a record, related RuleSet artifacts are also removed where applicable.
After Migration:
Refresh the Decision Tables (DT) used by DRO Fallout Management—Migrating the Fulfillment Fallout Rules records requires a refreshed Fallout Rules DT definition.
Refresh DTs used by DRO Jeopardy Management—Migrating the Fulfillment Step Jeopardy Rule records requires a refreshed Fulfillment Step Jeopardy Rule DT definition.
Activate technical products in your target org as part of your deployment.
These components have dependencies on specific features.
Enrichment Rule—Expression Set
Decomposition Rule with condition—Business Rules Engine Context Rule and Context Service
Callout step—Integration Definition
Autotask step—Flow
Manual Task step—Queue
Product Fulfillment Scenario with condition—Business Rules Engine Context Rule and Context Service
j