Admin Commandment #9 An Awesome Admin should protect their org… for more reasons than you think!

So here we are then with the penultimate post in the Admin Commandments series and this time we turn our attention to how us Awesome Admins should be protecting our org.

Let’s start with a simple analogy: Security is an Inside Out job! What does this mean!?! Well, from the outside, by protecting our org we’re talking about securing access by setting login hours, applying IP restrictions, enabling 2-factor authentication and a host of other security features which all help us ensure only the right users and systems can access our org from the outside. However, something which is often overlooked are the things we should be doing to protect our org from the danger lurking inside your own organisation. Often the least reliable component of any system is the person sat in the chair. Salesforce does a great job of protecting us from external nasties, but who protects us from ourselves?! Hence the analogy of Security is an Inside Out job!

We start with one of the most common pitfalls which new org owners and admins can fall into. Rolling out standard profiles to their user base. Whilst this is the quickest way to get started, it’s also opening up one of the biggest data holes in your org – the permission to delete records. OMG!! Yes, that’s correct, and we wonder here how many people actually realise this one up front. Opening up DELETE rights on critical data objects such as Accounts and Opportunities can potentially create some pretty big data nasties. We understand there are often justifiable reasons for deleting records – which normally falls under the guise of data clean up. However this activity, we hope, is not normal operation for your core user base.

So what are we saying here is… Don’t use standard profiles straight out of the box; always create custom ones and ensure that you limit delete rights for normal users. One exception to this would be Professional Edition users. The key thing to remember when designing your profiles is you should be aiming to provide exactly what each set of users need to perform their daily jobs and activities, and not access to features or records which do not fall within that. Give them what they need, but no more than that! But yes, we understand some users will from time to time need more permissions than their profile grants… so let’s nicely segue into our next point around Permission Sets.

Permissions Sets provide granular control of permissions with the ability to give specific sets of permissions to one or more users. In contrast to profiles, permission sets are about providing permissions for the most specific sets of user needs, compared to profiles which are about giving the minimum set of permissions to the broadest set of users.

One use case for Permission Sets is granting an increased level of access to data within your org for a temporary period of time. Now herein lies the danger, the process of assigning Permission Sets to users is a very manual task, but it’s not the assigning which really worries us here. It is the part where we forget we have actually grant these permissions in the first place and then forget to unassign the permissions when they’re no longer required. Obviously some people are better at remembering this than others, but the world is not perfect and neither are we. Forgetting to revoke something like this becomes a bit of time bomb just waiting to go off.

Our friend Rakesh Gupta, the Automation Champion, has kindly provided a spring board for solving this problem – at this point we’re just going to high five him and share the link with you: Add/Remove Permission Sets

Next we naturally come towards another internal security issue, one which we can hear you saying has never ever happened in your org… But are you sure? Come on, own up, who at some point has forgotten to deactivate a user who has left the company?

It may turn out that it was not forgotten entirely, just that they were not deactivated in a timely manner. Know this one? In most cases, people who leave organisations on their own accord don’t pose a threat here, but those terminated early are statistically more likely to access their old work systems after they leave. They could do something like download all your customer data, which is less severe than deleting records if you haven’t secured some of the holes mentioned previously. You really need use a ‘belt and braces’ approach here, and make sure you deactivate users in a timely manner. Don’t live to regret it.

We would go so far as to say automate this deactivation where possible. Large organisations will probably have smooth deactivation sorted via Single Sign-On means, but if you don’t have this luxury you could consider automating the deactivation of users after a period of inactivity. But to be honest any sort of delay to deactivation is too long… Just make it part of your standard procedures and stick to them!

So how else should we be looking to protect our org that perhaps we don’t think about?

Now let’s move towards how we can protect not just the org itself but the data within our org. A strong security model design proves invaluable here, ensuring Salesforce data is protected and visible only by the right people. But like all things, it is important to find the correct balance. As an example: a security model which is too tight may allow for duplicate data to creep in as sales reps don’t have the visibility to see there is already an existing account record. So you need to make sure the level of visibility fits the way you really operate – don’t be a paranoid android unless you really have to be!

Here is another feature to watch out for – one that can allow more data nasties to creep in if you don’t manage it properly – the “Edit Read Only Fields” permission. To us this is a bit of strange feature. There is a very strong argument that if a field is read only, then it should always be read only. The trouble with this one, and we can talk from experience here, is it’s fairly common for administrators to have this permission permanently but to forget they do. Let’s imagine you have some process which is maintaining the value of the field – this field is critical and drives a lot of reporting within the business. A new admin joins the company and doesn’t know that he/she can edit fields which are read only, so they manually change the value for some reason, even a legitimate reason in their eyes. This can potentially start a fire within your organisation until someone realises it was changed manually. It’s one of those things where you should 100% look to move into a permission set, and control the usage of that permission set strongly.

Okay let’s continue with one more, and this is one we see a lot – org processes which involving turning Validation Rules on and off, and in some extreme cases on a daily basis. Honestly, any sort of regular frequency here should highlight to you that something is adrift with the process anyway. There will be times when you have to and so we are not saying never ever. Let’s take importing leads or contacts which you have picked up from an event or to do some cold calling. We know this probably very contentious perspective, but why would the data you want to import be any different to the data you want to validate when entering using the standard salesforce UI? If you can bypass a validation rule, and find yourself choosing to do so regularly, that validation clearly isn’t being enforced consistently and therefore perhaps you don’t need it. Or you need to take a good hard look at the quality of the data you’re importing.

So to recap this commandment, here’s really what are we saying…

An Awesome Admin should be as mindful and keep abreast of all the external access points and the different ways the range of security features can be configured to ensure only the people and systems you want to can access the system.

If you feel you have gaps in your knowledge or don’t know where to start, then we recommend checking out Community rising star, Jen Lee’s series entitled “Security is Everyone’s job!” and of course, it would be rude not to mention… Yes, Trailhead!

Here are the Trails you need to kick start your learning: User Management, User Authentication, Identity Basics

That’s the areas which you make configuration changes to secure your org from the outside covered – then you need to think about whether you have taken some of the potentially dangerous paths we have mentioned that might sacrifice internal data protection, like:

Are you using standard out-of-the-box profiles…?

Have you given your normal users permissions to delete data….?

Have you left an entourage of permissions enabled in the profile for things the user just doesn’t need to do…?

Are you a lightning fast start-up with more licenses than you know what to do with, so you can’t be bothered to deactivate users once they leave or, even worse, when you’ve fired them…?

Is managing and toggling the validation rules in your org a full-time job…?

Trailhead proves invaluable again here to really maximise your knowledge , make sure you check out the Data Security Trial!

We hope you this has given you some food for thought and things to take-away, and also a broader picture of how and why you, as an Awesome Admin, should be constantly thinking of protecting your org and its data, from the inside out.