This Unlocked Package was developed for Marketing Admins who want to enforce the Campaign Member Status options for Campaigns of certain types.
This application is designed to run on the Salesforce Platform
- What You Get
- Installing the Unlocked Package Directly (Recommended)
- Pushing Code to a Sandbox org
- Post-Install Configuration
- Installing into a Scratch Org
- How it Works
- FAQ
When deploying this package to your org, you will get:
- 1 Custom Metadata Type (and page layout)
- 1 Campaign Custom Field
- 1 ChangeDataCapture configuration
- 2 APEX Triggers
- 5 Production APEX Classes
- 3 APEX Test Classes
Setup is a bit more of a breeze when you install the Package.
-
Install Unlocked Package (for Admins Only)
-
Continue with Post-Install Configuration
Follow this set of instructions if you want to deploy the solution into your org without using an Unlocked Package. This will require a Sandbox, and then a ChangeSet to deploy into Production.
-
If you know about and use
git
, clone this repositorygit clone https://github.com/sercante-llc/protected-campaign-statuses.git cd protected-campaign-statuses
or
- Download a zip file
- Extract the contents
- Navigate to the directory (sample commands below, though it may be different for you depending where you downlaod things)
cd Downloads/protected-campaign-statuses-master/protected-campaign-statuses-master
- Verify you are in the same directory as the sfdx-project.json file
# mac or Linux ls # windows dir
-
Setup your environment
-
Authorize your Salesforce org and provide it with an alias (myorg in the commands below)
# Connect SFDX to a Sandbox Org sfdx force:auth:web:login -s -a myorg -r https://test.salesforce.com # if for some reason you need to specify a specific URL, use this slightly altered command, making the correct adjustments sfdx force:auth:web:login -s -a myorg -r https://mycompanyloginurl.my.salesforce.com
-
Run this command in a terminal to deploy the reports and dashboards
sfdx force:source:deploy -p "force-app/main/default" -u myorg
-
Continue with Post-Install Configuration
- Once installed, create some Protected Statuses
- Log in to Salesforce Lightning, go to Setup
- Navigate to Custom Metadata Types, click Manage Records for Protected Campaign Status
- To create your first ones, click New
- Fill in the various fields
- Label: Used in the List of Campaign Statuses in the Setup view in step 3 above. Recommended convention: TYPE-STATUS
- Name: This is an API name that can be used by developers. Not required by this package. Recommended: let this autofill after you type in the Label
- Campaign Type: This is the actual value for the Campaign’s Type field.
- Protected Status: This is the Status value that will become protected
- Is Default: Select this if this Status should be the default (please pick only 1 per Type)
- Is Responded: Select this if this Status should be marked as Responded
- Click Save (or Save & New) and repeat a whole bunch
- Create a scheduled job to restore deleted protected statuses
- Back in Setup, go to Apex Classes and click Schedule Apex
- Fill in the few fields
- Job Name: give this a nice descriptive name so you remember what it is in 3 months
- Apex Class: SL_ProtectedCampaignStatusJob
- Frequency: set this to what works for you. We recommend running this daily during off-peak hours
- Start: today
- End: some time in the distant future
- Preferred Start Time: off peak hours
Once you have provided your statuses, you are good to go. Give it a whirl by creating a new Campaign with the Type that you have set up. Then take a look at the Statuses already created.
-
Set up your environment. The steps include:
- Enable Dev Hub in your org
- Install Salesforce CLI
-
If you haven't already done so, authorize your hub org and provide it with an alias (myhuborg in the command below):
sfdx force:auth:web:login -d -a myhuborg
-
If you know about and use
git
, clone this repositorygit clone https://github.com/sercante-llc/protected-campaign-statuses.git cd protected-campaign-statuses
or
- Download a zip file
- Extract the contents
- Navigate to the directory (sample commands below, though it may be different for you depending where you downlaod things)
cd Downloads/protected-campaign-statuses-master/protected-campaign-statuses-master
- Verify you are in the same directory as the sfdx-project.json file
# mac or Linux ls # windows dir
-
Create a scratch org and provide it with an alias (protectedstatuses in the command below):
sfdx force:org:create -s -f config/project-scratch-def.json -a protectedstatuses
-
Push the Source to the org
sfdx force:source:push -u protectedstatuses
-
Open the scratch org:
sfdx force:org:open
-
Continue with Post-Install Configuration
Once everything is set up (above), Campaigns should maintain a consistent set of Campaign Member Statuses. Here's how we accomplish that.
When a new Campaign is created, we check to see if the Type of Campaign is defined in any of the Protected Campaign Member Status records (the Custom Metadata Type that was set up earlier). If there is a match, the solution will:
- Automatically add a checkbox to the Campaign Custom Field "Has Protected Campaign Statuses".
- Automatically adjust the CampaignMemberStatus records to match all Protected Campaign Member Statuses expected
For a Campaign that "Has Protected Campaign Statuses", when one of the CampaignMemberStatus records is edited we will double check all statuses of that Campaign to make sure that all Protected ones still exist. If there are any missing, they will be recreated almost instantly (you may need to refresh the page for them to show up if there's a delay).
If a user removes a Protected Campaign Status, the Scheduled Job (that was created as part of Post-Install Configuration) will search for Campaigns missing a Status and recreate it.
We really wish we could. A "before update" and "before delete" APEX Trigger would be the simplest way to handle this. Unfortunately, APEX Triggers are not (yet) possible on CampaignMemberStatus records, so we end up having to fix it after-the-fact.
If you have APEX tests which set up a Campaign record as part of the test, the functionality in this package will get called and might blow up. This is because how Salesforce internally treats the automatic generation of Campaign Member Status records when a new Campaign is created (it's weird).
You have 2 options:
- For the purpose of the test, disable this functionality. You can accomplish this by adding
SL_CampaignTriggerHandler.bypass=true;
in your APEX Test set up. - To actually see the records that Salesforce would create, you would need to have your test
@isTest(seeAllData=true)
. There are a lot of considerations with this approach, so please use wisely.