Control Sandbox Deployments

In most environment, using a simple change set to move changes works just fine. Sure, adding components to the change set can be a bit tedious when you have to page through several screens to find the right custom field. And waiting 5 minutes for the change set to become available to deploy can be irritating when you’re trying to make it to your next meeting. But change sets are familiar to admins and trying to force a developer style process usually ends up causing more issues than it solves.

In this video I walk through a compromise between using change sets and using metadata api pushes.

Platform Events – Publish After Commit

So you want to integrate Salesforce with another system. There are a hand full of options.

  1. Outbound Messages
  2. Apex Callouts
  3. Custom C# / Java / etc code to pull data
  4. Streaming API
  5. Platform Events
  6. Mulesoft / Jitterbit / Talend / Azure Logic Apps / etc

Many projects use a combination of these features. Recently I worked on a project that was using a combination of Platform Events and Mulesoft to pull data out of Salesforce and load into a backend system near realtime.

I used Process Builder to trigger on a custom object’s Create/Update event and then send a Platform Event, which Mulesoft would respond to by reaching into Salesforce to read the data that was just created.

The problem was that Salesforce would send the Platform Event before the data was committed to the database and available for Mulesoft to read resulting in an “Invalid Cross Reference Id” (INVALID_CROSS_REFERENCE_KEY) error. Trying the read again few seconds later would work just fine.

In the Summer 19 release, there is feature to avoid this problem by adding a new Publish Behavior setting. The values are either “Publish Immediately” or “Publish After Commit” . Setting the Platform Event to publish after commit will make sure Mulesoft doesn’t try to read the data before it is actually available.