💃 Salesforce Data Security 🕺

Good morning, Salesforce Nerds! Show of hands 🖐️, how many of y’all eyes glaze over when people start talking security?

Filtering through mounds of objects & fields to determine who should see what? Trying to figure out what users needs to see what records?

It’s a daunting task. 🫢 

At the same time, it’s necessary. Especially if you work in an industry with sensitive data.

So I thought I’d write about it. Nothing that’ll break your brain. Just get you pointed in the right direction. ➡️ 

TABLE OF CONTENTS

Salesforce Data Security

• What to know first

• Object Level Security

• Field Level Security

• Record Level Security

• Summary

FIRST THINGS FIRST

WHAT TO KNOW FIRST

Salesforce data consists of:

👉️ Objects

👉️ Fields

👉️ Records

Objects are like database tables, fields are the columns, and records are the individual rows of data.

As Salesforce professionals, we have a tools at our disposable to secure our data at each of these levels 🔐 

TIER 1

OBJECT LEVEL SECURITY

The first layer of defense! 🚫 

Before a user can access data the platform checks if they have permissions to see objects of it’s type.

Makes sense, if I haven’t been granted the ability to see Accounts. Then I can’t access them at all.

The are configured two ways:

✅ Permissions Sets/Permission Set Groups

The preferred way to go. Offering a waaaaaay more flexible way to secure your data with the ability to create different permissions, group them together and attach one or more to user accounts.

Think of it this way … you just want to create different permission sets representing the different tasks that users perform in your system. 😃 

Like “Send Fax Packet”, “Convert Lead”, “Do The Thing”, etc.

These will each contain the settings to Create, Read, Update, or Delete (CRUD) on all of the objects that are necessary in each task.

Start putting them in Groups for manageability. If sending a fax packet and converting a lead are done by the same user, then throw them in a Group and attach the Group to these users. 🧠 

✅ Profile

The old school way. If you manage permissions this way then you have to put all your object and field permissions here. 👎️ 

Then anyone with that profile is granted those permissions.

In most real world scenarios there are users under the a profile that you need to restrict more than others.

Like Russ in payroll. 😠 

Because of this (and much more) Salesforce will not be investing any more time with security via Profiles.

TIER 2

FIELD LEVEL SECURITY

Assigning permission to see an object won’t do much if you can’t access any of it’s fields. 🙄 

We have the ability to assign read and write permission on individual fields for a given object.

If you don’t give a user permission to a field then the platform will restrict access to it from every entry point. ⛔️ 

It’s as if the field doesn’t exist.

This is a best practice when you want to restrict a field - don’t just remove it from the layout. 👍️ 

Again, the preferred method here is to use permission sets and permission set groups. But you can still assign these with profiles.

TIER 3

RECORD LEVEL SECURITY

Sweet, we’ve given access to an object and it’s field to our users. 🤙 

Almost there, right?!

Hang on there - this really only gives our users access to the records they own.

Then next thing we have to go into is record level security. How do we allow our users to see data that they don’t own?

Truthfully, this should be it’s own article, but let’s do a high-level overview:

✅ Org Wide Defaults (OWD) - control the default behavior of how every record of an object is accessed by non-owners.

✅ Role Hierarchies - control record access vertically throughout the org. Typically, job roles are sorted in a hierarchical way and users in a higher role need access to data that users in lower roles own. This is known as vertical sharing. That’s what this accomplishes.

✅ Sharing Rules - control record access laterally throughout the org. Many times a users peers in different roles will need access to data to do their job. Sharing rules allow you to share records in an ad-hoc fashion through your org. This could be it’s own article, too.

✅ Manual Sharing - let’s your users click a button and share a record one by one.

✅ Apex Sharing - If all else fails. Ask a dev to write some code. Each object comes with a sharing table that devs can write to with some Apex. 🦸 

SUMMING IT UP

SUMMARY

This is an important topic. I know it get’s talked about a lot. But, it also get ignored a lot, too.

In the day-to-day grind of daily stand-ups, plannings, retros, dealing with the problems Russ caused it’s easy to just click “Continue” and give everyone access to the field. 🤷 

Do yourself a favor and set aside time to ask these questions and configure these settings correctly.

You won’t regret it.

SOUL FOOD

Today’s Principle

and now....Salesforce Memes