For a long while, the common wisdom about the Salesforce security model has been that it is the panacea that will allow you to sleep at night. And that is mainly true; it is a robust tool that allows you to define user profiles and Roles, and Permission Sets and Sharing Rules. It allows you to restrict login by time and by IP address. And it certainly gives you the tools to set up OAuth authentication; and can behave as an Identity Provider (or even use an external idp) to authenticate against, or…

Well you get the idea. Salesforce gives you the tools to build a robust security model. And therein lies the false sense of security. You have the tools! Using these tools, and adding your own are the real challenge of securing your org.

The reason I say ‘adding your own’ is because you must recognize the shortcomings of the model, and provide additional layers of protection when the standard security model fails to fill the bill.

Recently, we were called in to set up an outbound calling program for a major US service provider. The company, recognizing the many pitfalls that are inherent in calling people without their permission, engaged its legal team to ensure that we solutioned to the very strictest security standards…well beyond those available ‘out of the box.’

Let me explain some of the challenges that you face when undertaking such a program. First, every US state has individualized rules surrounding when you can call a prospect. These are maddeningly inconsistent from one state to another, and your solution must adhere to each of those timing rules. In addition, national rules overlay upon the times with a set of behaviors with which you must comply. For instance, disable further attempts if you have unsuccessfully attempted to reach twice, or if you’ve been asked to ‘do not call’ that lead…

While these restrictions seem straight-forward, you must assure that your implementation team can guarantee that the lead is hidden or phone number obscured when any single calling rule is inactive. Think of the implementation as a funnel, with each dimension acting as a possible rejection (time of day, state restrictions, caller parameters, time-zone, public holidays, daylight savings time, whether caller is in a Daylight savings time region…and that’s just the initial, obvious items).

The key to a successful implementation of this sort is multi-fold. First and foremost, your team must be absolute stellar Salesforce security professionals. Do they understand how roles and profiles ‘really’ play together? Can you hold court on the nuances of org-wide-defaults, and can you overlay that security model with US government calling regs? If you don’t have such a person, find one and add him/her to your team. Quiz them on the details of Salesforce security tools. Prod them to identify where the Salesforce toolkit falls short, and then formulate a plan to mitigate those shortcomings. Finally, when your plan is in place and you are ready to go-live…STOP. Your next step is to….test, test, test. Try and break the model. Think like your line-agents when you look at leads. Can they circumvent your security model? Can they expose phone numbers even though you have hidden them from plain view? Are you absolutely sure?

Finally, legal is your friend in this effort. Don’t treat your legal team as a hurdle that needs to be jumped over (or barged through). Their input and oversight will prove to be the best safety-rail against potential disaster.

Security models take on a critical role when your data intends to touch outsiders. It is increasingly becoming clear that a misstep in securing your customer contact data can have catastrophic, and possibly terminal repercussions. Tread lightly and know your tools. If you do, you’ll be able to sleep at night.

Moyez Thanawalla is a senior Salesforce consultant with Thanawalla Digital in Dallas. He has architected security solutions for the largest Salesforce orgs worldwide. He is a 3x Salesforce MVP. You can reach him at moyez@t.digital