Skip to content

A Salesforce project that demonstrates how you can enforce Campaigns to have certain CampaignMemberStatuses based on Campaign Type

License

Notifications You must be signed in to change notification settings

sercante-llc/protected-campaign-statuses

Repository files navigation

Protected Campaign Statuses

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

Table of contents

What You Get

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

Installing the Unlocked Package Directly

Setup is a bit more of a breeze when you install the Package.

  1. Install Unlocked Package (for Admins Only)

  2. Continue with Post-Install Configuration

Pushing Code to a Sandbox org

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.

  1. If you know about and use git, clone this repository

    git clone https://github.com/sercante-llc/protected-campaign-statuses.git
    cd protected-campaign-statuses
    

    or

    1. Download a zip file
    2. Extract the contents
    3. 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
    
    1. Verify you are in the same directory as the sfdx-project.json file
    # mac or Linux
    ls 
    
    # windows
    dir
    
  2. Setup your environment

  3. 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
    
  4. Run this command in a terminal to deploy the reports and dashboards

    sfdx force:source:deploy -p "force-app/main/default" -u myorg
    
  5. Continue with Post-Install Configuration

Post-Install Configuration

  1. Once installed, create some Protected Statuses
    1. Log in to Salesforce Lightning, go to Setup
    2. Navigate to Custom Metadata Types, click Manage Records for Protected Campaign Status
    3. To create your first ones, click New
    4. Fill in the various fields
      1. Label: Used in the List of Campaign Statuses in the Setup view in step 3 above. Recommended convention: TYPE-STATUS
      2. 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
      3. Campaign Type: This is the actual value for the Campaign’s Type field.
      4. Protected Status: This is the Status value that will become protected
      5. Is Default: Select this if this Status should be the default (please pick only 1 per Type)
      6. Is Responded: Select this if this Status should be marked as Responded
    5. Click Save (or Save & New) and repeat a whole bunch
  2. Create a scheduled job to restore deleted protected statuses
    1. Back in Setup, go to Apex Classes and click Schedule Apex
    2. Fill in the few fields
      1. Job Name: give this a nice descriptive name so you remember what it is in 3 months
      2. Apex Class: SL_ProtectedCampaignStatusJob
      3. Frequency: set this to what works for you. We recommend running this daily during off-peak hours
      4. Start: today
      5. End: some time in the distant future
      6. 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.

Installing into a Scratch Org

  1. Set up your environment. The steps include:

  2. 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
    
  3. If you know about and use git, clone this repository

    git clone https://github.com/sercante-llc/protected-campaign-statuses.git
    cd protected-campaign-statuses
    

    or

    1. Download a zip file
    2. Extract the contents
    3. 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
    
    1. Verify you are in the same directory as the sfdx-project.json file
    # mac or Linux
    ls 
    
    # windows
    dir
    
  4. 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
    
  5. Push the Source to the org

    sfdx force:source:push -u protectedstatuses
    
  6. Open the scratch org:

    sfdx force:org:open
    
  7. Continue with Post-Install Configuration

How it Works

Once everything is set up (above), Campaigns should maintain a consistent set of Campaign Member Statuses. Here's how we accomplish that.

New Campaign Created

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:

  1. Automatically add a checkbox to the Campaign Custom Field "Has Protected Campaign Statuses".
  2. Automatically adjust the CampaignMemberStatus records to match all Protected Campaign Member Statuses expected

Editing a Protected Campaign Status

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).

Removing a Protected Campaign Status

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.

FAQ

Why Don't you just prevent people from messing around with Protected Statuses?

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.

I get APEX test errors after deploying the code. How can I fix them?

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:

  1. 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.
  2. 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.

About

A Salesforce project that demonstrates how you can enforce Campaigns to have certain CampaignMemberStatuses based on Campaign Type

Resources

License

Stars

Watchers

Forks

Languages