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.
Overview
MoveData creates a hierarchical set of campaign records depending on the data contained within a notification:
Campaign
Team
Fundraiser
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.
Default | Required |
[Insert] Draw.io Example | [Insert] Draw.io Example |
Implementation
Creating an SObject Flow
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.
Setting the SObject Type
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.
Dynamically Remapping the MoveData Metadata
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:
PIPELINE_DONATION_CAMPAIGN_FIELDSETPIPELINE_DONATION_CAMPAIGN_PLATFORM_KEYPIPELINE_DONATION_CAMPAIGN_DUPLICATEPIPELINE_DONATION_CAMPAIGN_NAMEPIPELINE_DONATION_CAMPAIGN_MAPPINGPIPELINE_DONATION_CAMPAIGN_POST
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.
β
Configuration Screenshot | Metadata Entry |
Set Fieldset Metadata Flow Action | Campaign Fieldset Metadata Replacement
|
Set Platform Key Flow Action | Campaign Platform Key Metadata Replacement
|
Set Record Match Flow Action | Campaign Record Match Metadata Replacement
|
Set Name Flow Action | Campaign Name Metadata Replacement
|
Set Mapping Flow Action | Campaign Mapping Metadata Replacement
|
Set Post Upsert Flow Action | Campaign Post Upsert Metadata Replacement
|
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.
Registering the SObject Flow
Related Article
For information on how MoveData handles the registration of flows, please see:
[Insert] How MoveData Handles Registration of Flows
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
Labelis an explicit key used by MoveData to located the registered entry, and in this case, it will bePIPELINE_DONATION_CAMPAIGN_SOBJECTMoveData Pipeline Setting Nameis not consumed by MoveData and as such can be anything you likeSet
Handleris the API Name of your FlowSort Orderis not important unless there are multiple flows trying to reset the SObject type and can have any numerical value (default MoveData flows use a sort order of 5)Set
TypetoFlow
Outcome
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:














