Considerations for Migrating Expression Sets

Here are some considerations to keep in mind when you plan the migration of expression set and expression set versions by using Salesforce CLI (SF CLI), Workbench, Change Sets, or any other migration tool.

Note Although SF CLI supports migrating complete expression sets and decision matrices, it doesn’t support migrating individual versions. To deploy a single expression set version, first retrieve it via a package.xml manifest file, and then deploy it using another tool apart from SF CLI. See Sample package.xml Manifest Files.

Scenario 1: Migrate a new expression set

If the target org doesn’t contain the expression set that you want to migrate, deploy the expression set along with its versions from the source org to the target org. If you specified ranks on the expression set versions in the source org, they operate at the same ranks after the migration. If the expression set contains dependencies, follow the recommendations in Scenario 3: Migrate expression set versions with dependencies.

Scenario 2: Migrate updates to an expression set

To update an expression set that exists in the target org, migrate a new expression set version with the updates; don’t update the existing active versions.

You can create an expression set version in the source org with the updates. Specify a rank and activate the new version in the source org. Then, migrate the new version or the entire expression set to the target org. The migrated expression set version is invoked in the target org as per the specified rank. Migration fails if the target org already contains an expression set version with the specified rank.

If the expression set contains dependencies, follow the recommendations in Scenario 3: Migrate expression set versions with dependencies.

Consider these points when you migrate an expression set or an expression set version.

• The migration result depends on whether the expression set and its versions exist in the target org, and on the status of such versions.
• Expression set versions are migrated to the target org in the same state as in their source org.
• Expression set versions in the target org aren’t deleted irrespective of their state. Manually delete expression set versions that you don’t require in the target org.
• When you migrate an expression set version that isn’t in the target org, it’s deployed from the source org to the target org.
• When you migrate an expression set version that’s inactive in the target org, it’s replaced by the version in the source org. The migrated expression set version from the source org overwrites the inactive expression set version in the target org.
• When you migrate a modified expression set version that’s active in the target org, it fails and the version in the source org doesn’t overwrite the active version in the target org.
• If both the source and target orgs have a version with the same developer name, regardless of its active status, make sure that the version number in the target org remains unchanged and matches the version number in the source org.

Let’s review these considerations with an example of an expression set named FeeCalculator used by an educational institution. FeeCalculator version, v1 is used to calculate the fees of a student based on the selected course, entrance examination rank, and application category in the target org. Now, the institution wants to include discounts based on the calculated fees. Accordingly, the rule designer creates another expression set version, v2 in the source org to incorporate the new criteria, and tests the version with sample data. The rule designer either migrates the entire expression set or only version v2 to the target org. The migration behavior depends on the status of the FeeCalculator version in the target org.

Scenario 3: Migrate expression set version with dependencies

Expression set versions can reference dependent elements such as decision matrices, decision tables, subexpressions, context definitions, field and object aliases, and explainability message templates. In such cases, migrate the dependent elements independently before you migrate the expression set version itself. You can deploy an expression set along with its immediate dependencies simultaneously. If those dependencies contain further nested dependencies, migrate the lowest-level dependencies before you deploy the parent expression set. For more recommendations and examples of expression set versions with dependencies and contarct-breaking changes, see How to Migrate Expression Sets with Dependencies.