Loading
Salesforce now sends email only from verified domains. Read More
Business Rules Engine
Table of Contents
Filter by (0)Add
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

            Search all of Salesforce Help
            Search all of Salesforce Help
            Migration of Expression Sets with Dependencies

            You are here:

            1. Salesforce Help
            2. Docs
            3. Business Rules Engine

            Migration of Expression Sets with Dependencies

            Expression set versions can reference elements such as decision matrices, decision tables, subexpressions, context definitions, field and object aliases, and explainability message templates. Migrate the dependent elements independently before you migrate the expression set version.

            Required Editions

            Available in: Lightning Experience
            Available in: Enterprise, Unlimited, and Developer Editions for clouds that have Business Rules Engine enabled

            This image depicts the dependencies among components typically used in expression sets. To migrate these components, start from the independent components in Level 1 of the Deployment Order and move up along the order.

            Dependency chart for migration of BRE components

            Consider these recommendations.

            • You can deploy an expression set along with its immediate dependencies simultaneously. If those dependencies contain further nested dependencies, then migrate the lowest-level dependencies before you deploy the parent expression set.
            • Migrate the lookup tables before you migrate the expression set and subexpression versions.
            • If the expression set version contains a context definition, then migrate the context mapping, and context definition independently. Activate the definition, and then migrate the expression set.
            • If the expression set version uses field aliases for the fields on custom objects or the custom fields on standard objects, then make sure that you migrate the dependencies before you migrate the expression set version.
            • If the expression set contains a decision table that uses the fields on a custom object or the custom fields on a standard object, then make sure that you migrate the dependencies before you migrate the decision table, and then migrate the expression set that contains the decision table.
            • Deactivate lookup tables, and then migrate them. The migration of a lookup table deploys the metadata of the lookup table and not the data. Import data into the lookup tables after the migration is complete and then activate the lookup tables.
              • After you migrate a decision matrix without row data, open the decision matrix version in the target org, and then upload the row data by using the Upload CSV File option.
              • After you migrate a decision table without row data, refresh the decision table with the latest data in the object that it refers to.

            Here are a few dependency scenarios in expression sets and the recommended migration steps.

            Use case Components Scenario Migration Steps
            Expression set with two levels
            • Parent expression set - PES
              • Expression set - ES
            		 PES calls ES. Deploy PES and ES together.
            Expression set with more than two levels
            • Parent expression set - PES
              • Expression set - ES
                • Child expression set - CES
            • PES calls ES.
            • ES calls CES.
            • Deploy CES.
            • Deploy ES and PES together.
            Multi-level expression set with decision table
            • Parent expression set - PES
              • Expression set - ES
                • Child expression set - CES
                  • Decision table - DT
                    • Custom Object - CO
            • PES calls ES.
            • ES calls CES.
            • CES imports DT.
            • DT is based on CO.
            • Deploy and populate CO.
            • Deploy and activate DT.
            • Deploy CES.
            • Deploy ES and PES together.
            Multi-level expression set with context definition
            • Parent expression set - PES
              • Expression set - ES
                • Child expression set - CES
                  • Context Definition - CD
                    • Context Mapping - CM
            • PES calls ES.
            • ES calls CES.
            • CES uses CD.
            • CD is based on CM.
            • Deploy CD and CM, activate CD.
            • Deploy CES.
            • Deploy ES and PES together.

            When the input or output variables in a new expression set version are changed or deleted, it constitutes a contract-breaking change. You can't migrate an expression set version with a contract-breaking change directly. However, you can save it as a new expression set, and migrate the new expression set. These examples illustrate this concept.

            Use case Components Changes to components Migration Steps
            Expression set version without contract-breaking change
            • Parent expression set - PES
              • Expression set - ES1 with version EV1

            EV1 variables:

            • Input - IV1, IV2
            • Output - OV1, OV2

            PES calls EV1 in the source org.

            Migrate PES and ES1 with EV1 to the target org.

            In the source org, create EV2 in ES1 with the required changes.

            EV2 has the same variables as EV1.

            • Input - IV1, IV2

            • Output - OV1, OV2

            Activate, rank, and deploy EV2 to target org.

            PES calls EV2 of ES1.
            Expression set version with contract-breaking change
            • Parent expression set - PES
              • Expression set - ES1 with version EV1

            EV1 variables:

            • Input - IV1, IV2
            • Output - OV1, OV2

            PES calls EV1 in the source org. Migrate PES and ES1 with EV1 to the target org.

            In the source org, create EV2 in ES1 with the required changes.

            EV2 variables are different from EV1 variables.

            • Input - IV1, IV2, IV3

            • Output - OV1

            Migration of EV2 to the target org fails.

            Here are the recommended migration steps.

            • In the source org, save EV2 as a new expression set ES2. ES2 has version EV2 with the updated logic.
            • Migrate ES2 to the target org.
            • Update PES ‌to call ES2 instead of ES1 in the target org.
             
            Loading
            Salesforce Help | Article