This page contains technical information for experienced Salesforce Administrators who are looking for a deeper explanation of the key jobs that run as part of the Campaign Monitor for Salesforce application.
The following table provides a list of Campaign Monitor for Salesforce batch jobs that can run in the backgroun within Salesforce.
|CMBatchCampaign||Pulls in Email History from Campaign Monitor into Salesforce. The records are stored in Email Tracking History (wbsendit__Campaign_Activity__c). This table can contain a large number of rows. See: Storage. This job runs as part of the main sync between Salesforce and Campaign Monitor.|
|CMBatchCampaignStats||Updates any linked Salesforce campaigns with statistics from the related Campaign Monitor campaign (E.g. number of clicks, bounces, unsubscribed etc). This job optionally runs as part of the main sync between Salesforce and Campaign Monitor. It runs if the following setting is set to active Update Salesforce Campaign statistics with Campaign Monitor statistics. See: Manage Campaign Settings|
|CMBatchDeleteSubscribers||Run as part of the Import Wizard job. It removes any subscribers from Campaign Monitor that were not in the Import Wizard report or list view. If there are a large number of subscribers to remove from Campaign Monitor, this job can take a long time to complete (if this is the case, you could also consider creating a completely separate Subscriber list for the import and deleting the old list - as this could be more efficient).|
|CMBatchEmailOptOut||This batch updates the standard salesforce email opt-out field on the Contact and Lead records based on the subscriber status. It will opt out any subscribers that are unsubscribed from all subscriber lists within Campaign Monitor. This job optionally runs as part of the main sync between Salesforce and Campaign Monitor. It runs when the following setting is active Set Email Opt to true when a Contact or Lead is unsubscribed or deleted in all lists|
|CMBatchSubscriber||Updates Salesforce with the status of any subscribers it finds in Campaign Monitor. Depending on how the custom mappings are configured, it may create and link new subscribers as Contacts or Leads in Salesforce along with any mapped fields. This job runs as part of the main sync between Salesforce and Campaign Monitor.|
|CMBatchSubscriberStats||Updates Salesforce subscriber lists with statistics from the related Campaign Monitor subscriber list (E.g. number of clicks, bounces, unsubscribed etc). This job runs as part of the main sync between Salesforce and Campaign Monitor.|
|CMConfigBatch||Syncs Campaign Monitor configuration data with Salesforce. This includes syncing any Campaign Monitor lists, clients and users with Salesforce. For example, if a user has created a list directly in Campaign Monitor, then this job needs to have run before it will appear in Salesforce. This job runs as part of the main sync between Salesforce and Campaign Monitor.|
|CMScheduleSubscribers||This is a schedulable job that is called from sendItScheduleSubscriptions when the sync is enabled. It starts the main sync between Salesforce and Campaign Monitor.|
|ImportListViewBatch||Called from the Import Wizard, this imports subscriber details from a Salesforce List View into Campaign Monitor. It can run as a once off manually initiated job or via a scheduled process (if the user has configured this via the Import Wizard).|
|ImportScheduler||Scheduler for running Import Wizard jobs. It runs hourly under the Salesforce user who requested the scheduled import jobs.|
|ProcessAsyncRecords||This is a queuable job that runs if it needs to send Salesforce data to Campaign Monitor. It can be invoked from a trigger or process builder action. It can result in a temporary Queue Item (Queue_Item__c) record being created. It will typically only run if it a) fields have been mapped from Salesforce to Campaign Monitor for an Account, Contact or Lead, or b) if there are automatic subscription rules that meet the criteria for a Contact or Lead. If there are too many jobs in Apex Jobs, then it's possible there is a race condition occurring (see below).|
|ProcessAsyncRecordsBatch||This is a batch job that runs if it needs to send Salesforce data to Campaign Monitor. It is similar to ProcessAsyncRecords in that it can be invoked under the same conditions. The difference is that it will run when there are multiple records that need to be processed. It typically works by processing items held in a custom object called Queue_Item__c. It will continue to process these records in sets. If there are still more items to be processed in the Queue_Item__c object, it will respawn itself.|
|RefreshCampaignHistory||Manages the space used by the Email Tracking History object. See: Storage. This job can take a long time to run if a full re-import Campaign Monitor data into Salesforce has been requested. See: Maintenance|
|RefreshSubscribers||Used when a user has requested a full re-import Campaign Monitor data into Salesforce. See: Maintenance|
|ReportToListBatch||Called from the Import Wizard, this imports subscriber details from a Salesforce report into Campaign Monitor. It can run as a once off manually initiated job or via a scheduled process (if the user has configured this via the Import Wizard).|
|SmartEmailBatch||Updates Salesforce with smart email template details fetched from Campaign Monitor. This job runs as part of the main sync between Salesforce and Campaign Monitor. See: Transactional|
|SmartEmailDetailsBatch||Updates Salesforce with smart email template variable details fetched from Campaign Monitor. This job runs as part of the main sync between Salesforce and Campaign Monitor.|
|SmartEmailTaskDetailsBatch||Updates tasks in Salesforce that were sent as part of a smart email. It pulls in the actual text that was sent to the subscriber. This job runs as part of the main sync between Salesforce and Campaign Monitor.|
If bespoke triggers or processes are built on one of the Campaign Monitor for Salesforce objects (E.g. wbsendit__Subscription__c OR wbsendit__senditcampaign__c), this can lead to a race condition. This could result in a large number of ProcessAsyncRecords jobs appearing in Salesforce Apex Jobs (I.e. Setup-->Jobs-->Apex Jobs).
The problem can occur if the bespoke code (i.e. code not written by Salesforce or included in Campaign Monitor for Salesforce), performs an action (update, insert or delete) on an Account, Contact or Lead based on the results of the Campaign Monitor for Salesforce objects. If the Contact, Lead etc has a rule associated with it (E.g automatic subscription rule or custom field mapping), then Campaign Monitor for Salesforce may re-fire the rule if it meets the condition. When the rule triggers an action, it will process it as a queuable item, which means it's disconnected from the original request.
For example, if a custom trigger is created to update the Contact based on the status of the subscription record and there is a rule on the Contact record that says add or remove a subscriber based on another condition, then this could result in the ProcessAsyncRecords being kicked off and as a result there will be an indefinite loop.
If there are numerous ProcessAsyncRecords jobs in Apex Jobs:
- Temporarily turn off the Campaign Monitor for Salesforce triggers (i.e. General Settings —> Sync Settings —> Disable Salesforce account, Contact and Lead triggers).
- Remove any triggers or process builder actions that touch wbsendit__Subscription__c or other wbsendit__* objects.
- Once you have done the steps above, Re-enable General Settings —> Sync Settings —> Disable Salesforce account, Contact and Lead triggers.
NB. As of release 6.29.8, the Campaign Monitor triggers will not fire if it detects that the job was called from a future or batch method. This is to help reduce the likelihood of a race condition.
The Salesforce Process builder is a powerful tool and when combined with Campaign Monitor for Salesforce, it provides fine grain control over sending targeted transactional emails to subscribers.
The trade off comes with the complexity of setting up and debugging processes. To help troubleshooting emails not sending, you can test the last step in the process builder action with the code below (E.g. try running the code in the Salesforce Developer Console). This is essentially the code that is called when you use the smart email invokable action in the process builder. If the code below works, then any problems are likely to be related to the fact that the invokable action is not being triggered (E.g. a status on a field used in your Salesforce process builder logic may not be correct etc).
There are two main variables you need to find and use:
- RootObject (Record Id) - This is the Id of the Salesforce record (E.g. Contact Id, Lead Id etc.).
- SmartEmailId (Smart Email Mapping Id) - This is the Id found on the Smart Email Mapping record.