This article details how to configure MoveData to use a different SObject type instead of the MoveData Extension defaults. In this example we will focus on the Campaign phase but note that the below logic is compatible in all phases of the execution. This article will also describe how to use a combination of SObjects for different types of Campaign records.

MoveData creates a hierarchical set of campaign records depending on the data contained within a notification:

Whilst this standard configuration works for the majority of customers, occasionally an organisation may have different requirements as to how they structure their campaign data.

In this example we will be using the Opportunity record for the fundraiser campaigns.

Create a new flow (from Setup → Process Automation → Flows) of type Autolaunched Flow (No Trigger).

In this example, the first check is to evaluate the Type of campaign being executed. We perform an evaluation for the input-enabled Text variable named Type:

Evaluate Type Flow Action

If Type equals fundraiser then MoveData will override the SObject and associated metadata entries. If not, the NPSP extension flows will continue to execute per their default behaviour.
​

Flow Diagram Example

When setting an alternative SObject type, there are two distinct actions you need implement in your flow: setting the SObject Type and remapping the flow metadata to be used for the rest of the execution. The reason the flow must the remap flow metadata is because the the existing flows are expecting a Record of type Campaign. If the wrong SObject type is sent to these existing flows, there will be a critical error and the processing will fail.

Set SObject Flow Action

This step sets the output-enabled Text variable Result to Opportunity. The value that must be used is the API name of the SObject. If you are using a custom object, this will look like Fundraiser__c. If the custom object belongs to a namespace, it will look like npsp__Fundraiser__c.

Remapping Key Flow Action

MoveData is directed by Pipeline Metadata Entries; these tell the engine when to execute specific Pipeline Metadata flows. For this example, we have installed the MoveData NPSP Extensions which adds a suite of metadata entries to execute its flows. When we have a campaign Type of fundraiser, we have determined we want to work with an Opportunity record. This means we will need to dynamically set alternative metadata that works with the Opportunity object.

To do this, we need to create an output-enabled Text collection variable named ExecutionMap that will contain all the replacement metadata keys. The keys we replace can be found in the appropriate extension documentation; the Fundraising & Donation extension documentation (link).

Each value used in the Remap must also be configured as an output-enabled Text collection variable. In this example, we have six variables we have created with the following names:

The below table details the settings for each one of these metadata entries. Please note that you will have to create the fieldset and flows that contain the new logic and the values below are for reference only.
​

If a metadata entry needs to be removed but not replaced with another flow, this can be done by leaving the value field empty when adding a value to the appropriate text collection.

We have now created the appropriate configuration for replacing the fundraiser campaign records with an Opportunity record and, in this scenario, will dynamically direct MoveData to execute an alternative set of metadata entries.

We need to register our new SObject flow for the Campaign phase. This is done by creating a new entry in the MoveData Pipeline metadata settings with following details:

Campaign Phase SObject Registration Example

Below is an example of a before and after for the created Flow:

From the execution log, we can see the SObject types for each of the campaign entries: