Entries by sfgeneral (301)


Sending emails from Salesforce? Add DKIM...

I was recently troubleshooting an issue with a customer not getting emails I was sending out of Salesforce. It's been years since I even looked at how a mail server works and I went down one of those dev rabbit holes to learn everything I could over a few hours.

One thing lead to another I ended up reading about DKIM (DomainKeys Identified Mail). What I found was the customer who was not getting my emails from Salesforce was in fact getting them they were just getting caught in their SPAM filter. DKIM is designed to help prevent that. The idea behind is that the receiving mail server and spam filter may try to see if the IP address sending the email is the same as the sender's domain. In this case the email is being sent from Salesforce with my email address ( DKIM is a mechanism to make that "sending on behalf of..." look more legit. 

Salesforce added support for DKIM back in Spring 15' and I just never had issues and therefore never looked into it. The idea being that if the digital signature checks out, it provides recipients more confidence that the email being handled by Salesforce has been authorized. It's pretty easy to setup and test and should hopefully increase your email deliverability out of Salesforce.

 1) Navigate to Setup > Email > DKIM Keys


 2) Click Create New Key

3) Enter a selector. In my case I used the word "salesforce". This is going to end up being entered into your DNS record so something short and sweat like "salesforce" or "dkim1" is great. The domain is the "sender" domain (your email domain).

4) Save it. This will generate a "public" and a "private" key 

5) Leave it unactive - but you're going to copy these values to your DNS. So wherever you have registered your domain (GoDaddy etc) you are going to login there and add a new TXT record (GoDaddy Example).


From the info above that we generated the two important bits of info are the "selector" and the "public key". In the release notes for the feature these keys are described about two thirds of the way down the page (Update your domain’s DNS records).

 For GoDaddy, my "Selector" is going to be salesforce._domainkey (salesforce was the name we gave when we defined the DKIM key. And the value for that key is the "public key" string from the textbox.

Once you save that in the DNS record (give it a few minutes to an hour), you can hop back over to Salesforce and activate the key.

When you do so, click on the name to open it up and you should see a green mark at the top noting that it found this DNS TXT record you just added.

DKIM is now enabled!!!



Salesforce Bulk API 2.0 (bigger, stronger, faster)

Bulk API 2.0 is in GA and available from API v41 and up. Highlights for me include:

  1. More, more, more. Higher daily limits. Load up to 100 million records in a 24-hour period.
  2. All the OAuth flows are now supported (OAuth 2.0) - same are the other REST API's
  3. File Batching - automatic batching. To me, this is big. No need to break up data into chunks, you just upload your monster CSV and check back for the results later.

Developer docs here

Sample CSV located here



NIght night IDE Beta 2

We had a good run buddy! No future releases will be provided after May 23rd (today). Sad right? It's okay because the extension pack for Visual Studio Code has come a long way. Tons of commits and I LOVE the syntax highlighting. 



Salesforce Sandbox Breakdown

 Best Practices in terms of team setup

Develop in Isolation

  • DO NOT use production
  • If you share a dev org, try to do it on a per object or per work item basis
  • If possible - don't share dev orgs!


  • Synchronize with peers to not only leverage each others work but as a way to do peer review
  • Find stable checkpoints or phase gates to handoff between functions (ex: QA)

When to Integrate

  • Integrate when complete
  • Integrate with peers when development and unit test coverage is complete
  • Itegrate with the current production setup for testing and sign off

Salesforce APIs and What They Are For...


What can you use it for


Access the different objects in your org using standard REST protocols


Integrate your org’s data with other applications

Bulk API

Insert, delete and perform Async queries against large data sets

Metadata API

Build tools that manage your metadata model and make customizations in your org

Streaming API

Send/Receive secure notifications. These notifications can reflect data changes in your org or even custom events

Tooling API

Build custom development tools for different Salesforce Platform applications

Chatter REST API

Build a UI for Chatter, Files, Topics, Communities and more

Marketing Cloud API

Get comprehensive access to most email functionality with the SOAP API.

Mobile SDK

Integrate native or hybrid mobile apps directly with Salesforce


Salesforce DX - Scratch Orgs vs Sandboxes

Most of us on the Salesforce platform are well aware of Sandboxes but I'm starting to get more and more questions on "Scratch Orgs". More specifically, what is the difference between a Sandbox and a Scratch Org and when to use one over the other. 

Let's start with a simple statement - Scratch Orgs are NOT meant to replace Sandboxes but rather be used in conjunction with.

The scratch org is a source-driven and disposable deployment of Salesforce code and metadata. Scratch Orgs are driven by source, Sandboxes are copies of production.

Scratch orgs do not replace sandboxes. Scratch orgs are not permanent and they don't include any production data. 

Scratch orgs complement Sandboxes. They are great for temporary deployments. We typically use them for peer review and a way to get enhanced test coverage and automation.

Sandboxes are still critical for staging, performance testing, licensing etc.


  • You can have up to 25 active scratch orgs
  • They automatically get deleted after 7 days
  • You can create up to 50/day per Dev Hub

Key Benefits

  • Increased Developer productivity
  • Better and easier Team Collaboration
  • DevOps Automation (my favorite)



Salesforce Sharing Model Visualized


Salesforce Security Model

Sometimes it helps to have a picture to put with what you are reading. Below is a handy little diagram that outlines the FLS (Field Level Security), Sharing and CRUD that makeup the Salesforce security model.

CRUD - Create, read, update, delete. Which objects the user can see in Salesforce.

Field Level Security (FLS) - which fields on a record can the see or edit

Sharing Rules - which specific records are visible to the users.


SOSL WITH HIGHLIGHTING (part of Spring '17)

I'm super excited about this update being released as part of Salesforce Spring '17 (works in both SOAP/REST API 39). I've been testing it out in my sandbox. Below is a simple example of the syntax:

FIND {salesforce} IN ALL FIELDS RETURNING Lead (Company, Description) WITH HIGHLIGHT

This functionality works on the following fields types (as of right now):


  • Email
  • Text
  • Text Area
  • Text Area (Long)


You can run this simple example in the Developer console and see that it returns the results with the <mark> tag around the term.

With this functionality, it is now pretty easy to search through a lot of record data for very specific things and return back a nice highlighted list of the results without having to use or build some form of custom control.