Salesforce Data Security – WeLearnSalesforce

Salesforce Data Security: Trusted IP Ranges versus Login IP Ranges. This one always twists my brain 🤯

A Salesforce org is like a multi-level office building. If you have a meeting with a customer in their office building on the 13th floor, you have to get through several security checks in order to meet them there. Starting with the main entrance, followed by the elevator, followed by the office entrance, followed by the meeting room. Each one requires a security pass to get through. Salesforce’s data security model works just the same. In this article we want to focus on the ‘main entrance’ security check. I’ll walk you through the options Salesforce checks for when someone attempts to enter a Salesforce org, including the importance of Trusted IP Ranges as well as Login IP Ranges.

Author: Peggy Schael | Salesforce Trainer | WeLearnSalesforce

How Salesforce Trusted IP Ranges and Login IP Ranges Fit in With The Data Security Model

Salesforce’s data security model essentially consists of four layers:

The first layer determines a user’s access to the Salesforce organization, like their username and password, and also their login location such as their IP address.

The second layer determines what users can see and do in Salesforce such as viewing specific types of records (a.k.a. Objects), edit or delete records.

The third layer specifies whose records users can access. Not only records they own or created, but also records of their colleagues.

And the fourth layer is all about the level of detail (=fields). How much information should a user be able to see. For example, should a sales user be able to see credit card information? Possibly not! But the finance department may need to.

This means, the first layer is your ‘main entrance’ security check of the office building, a.k.a. your Salesforce org.

What Does Salesforce Check For When A User Attempts To Log In

User authentication starts by entering a valid username and a password. If that is a match, Salesforce checks whether the User has logged in before or not. What happens it that Salesforce places a cookie in the user’s browser (unless the browser uses a cookie blocker). If Salesforce finds the cookie, it will grant access. If it doesn’t find that cookie, it will require the user to verify themselves.

This means they will receive an email notification under their registered email address containing a verification code. Once they enter the code and verify, they will be able to login.

Whitelisting Login Locations With Trusted IP Ranges

While this verification process is an important security measure, it can become rather bothersome when users switch locations from time to time or switch computers or browsers they work from. We are talking about IT users supporting a Salesforce org, or Salesforce trainers like myself, or team managers etc.

I remember one particular training roster with a government customer. There were several training sessions happening in different office location. Plus they were happening in different Sandboxes, hence different Salesforce logins. Each time I had to verify myself, and that turned out to be very time consuming, not only for myself but for the trainees too. So I took the IP addresses and whitelisted them. Problem solved!

Whitelisting IP addresses is done under Setup/Network Access by adding Trusted IP Ranges. This means. If a user tries to log in from within a Trusted IP Range, they do not have to go through the verification process.

In other words, if they try to login from outside a Trusted IP Range, they will only get access after they completed the verification process explained above.

IMPORTANT NOTE: This verification method is (currently) not supported in combination with Multi-Factor Authentication (MFA). Since MFA has been enforced in all Salesforce orgs, the cookie placement has become redundant (for now, as always check the release notes for updates). This means, every Salesforce user trying to log in to a Salesforce org has to confirm their authenticity through a MFA method, like using the Salesforce Authenticator app. MFA can theoretically be turned off, making the verification process relevant again. I’m NOT saying you should turn it off though, just something to keep in mind.

Restricting Login Locations With Login IP Ranges

Here comes the brain twister. A Salesforce Admin can restrict access to specified IP Ranges. Let’s say, you want to ensure that your Salesforce users can only ever log in to their Salesforce org from their office building. Some organizations like banks, hospitals, government agencies etc. with extra high security measures, may prohibit anyone to work outside of their office, or access their Salesforce org from outside their office. Some organizations though use VPN to enable users to work from home. But still, access is limited to the VPN connection.

Restricting the locations users are allowed to log in from is done by adding Login IP Ranges to User Profiles. Here’s what this does: When a user attempts to login from outside the listed Login IP Range, Salesforce recognizes the setting on the user profile, and the user will not be able to log in, at all.

Salesforce Data Security with all its different security layers is covered in detail in our comprehensive Salesforce Administrator Certification Course. It’s all connected! I walk you through each step, building up your expertise as you progress. 🤓

Restricting Login Based on Login Hours

Apart from the login location, Admins can also restrict access by office hours. Let’s say a Marketing user should only be able to access Salesforce during office days and office hours. However a Sales user needs to be more flexible to accommodate their customers, and should therefore be able to access their customer data on Salesforce 24/7.

There would be nothing to do for the Sales user, however for the Marketing user, you’ll need to add Login Hours to their respective User Profile. Be aware when locking an entire day, like Saturday and Sunday, you’ll need to select the same start and end time.

Once this has been added, upon login attempt, Salesforce will check the user’s associated Profile to verify whether there are any Login Hour restrictions to determine whether or not the user will be allowed to log in.

Managing Password Policies

Remember from earlier that the very first items Salesforce verifies are username and password. This is the very first security check to overcome. Therefore, we want to make this part as difficult as possible, especially for unauthorized people.

That’s where the Password Policies come in. You’ll use them to specify things like password complexity, number of login attempts, how often passwords need to be changed and more. But don’t make too hard though, otherwise you may loose on user adoption…

I hope this helped untie the twists in your brain. Do let me know what you find most difficult when it comes to managing data security in Salesforce. I’d love to know!

WHAT ELSE…

We make learning simple with our range of well-structured Salesforce Video Tutorials, downloadable Study Workbooks and realistic Practice Exams.

And if you are brand new to the world of Salesforce, make sure to sign up to our FREE 21-Day Salesforce Beginners Challenge.

Managing User Permissions – Best Practices & What Is Happening To User Profiles

Managing User Permissions in Salesforce has always been quite the challenge. Especially when you are new to Salesforce. The entire topic of data access and security can make you want to bang your head against a wall. The good news is: Salesforce provides cushioning. This means, Salesforce heard you and is making user permission management a fair bit easier. In this article, we’ll discuss what is happening to User Profiles and how you should be using Permission Sets moving forward.

Author: Peggy Schael | Salesforce Trainer | WeLearnSalesforce

How Salesforce User Profiles and Permission Sets Fit in With The Data Security Model

Salesforce’s data security model essentially consists of four layers:

The first layer determines a user’s access to the Salesforce organization, like their username and password.

The second layer determines what users can see and do in Salesforce such as viewing specific types of records (a.k.a. Objects), edit or delete records.

The third layer specifies whose records users can access. Not only records they own or created, but also records of their colleagues.

You guessed it! User permission management therefore belongs to the second layer of the data security model, even before you determine whose records or what fields they get access to.

Types of Salesforce User Permissions – What Users Can SEE and DO

As mentioned earlier, the second layer determines what users can see and do in Salesforce.

What users can ‘see’ relates to settings which specify which Apps users will have access to from the App Launcher and which tabs will be available in the navigation bar. Even if you give Users access to the Sales App for example, you can still restrict access to the Opportunities tab if they wouldn’t require access to this particular tab.

You can also specify what types of records users can see. For example, Accounts may be differentiated by Customer Accounts vs Partner Accounts. Some users may only need to see one or the other.

Plus, the ‘see’ permissions also determine how pages and fields will be displayed to users. You can arrange the order of the information, group them, highlight important details etc.

What users can ‘do’ with what they can ‘see’, is all about what they will be able to do within the Apps, Tabs and Pages they have access to.

This includes Standard Object permissions such as creating opportunity records. Or Custom Object permissions such a creating candidate records.

You also have App Permissions available to choose from. These are permissions only relevant to a specific app to fulfil a particular task, for example converting leads as part of the Marketing App.

And then there are System Permissions which are cross-object permissions like creating reports or creating list views and so on. This means, these permissions are relevant for all types of records.

Salesforce Data Security and Access is part of our comprehensive Salesforce Administrator Certification Course. You’ll learn how it all connects to Salesforce Objects, User Setup and more:

Tools To Assign Salesforce User Permissions

Let’s go back to the future first and understand how things used to be done, and are partially still going to be done. Then, we’ll look into to the future to see what Salesforce is going to change and make easier.

The tools available to a System Administrator to manage user permissions are Profiles, Permission Sets and Permission Set Groups. BTW, these are not going to change as such. Phew! 😅

Let’s start with Profiles and how they have been working up until now: Profiles are used to specify a baseline of permissions users require to do their jobs. Hence, an Admin would pick form the types of SEE and DO permissions to determine this baseline. For example, the Admin would include the Read permission on the Accounts Object.

Such a Profile will then be assigned to one or more users within a particular job function or department. This means, a Profile is often assigned to multiple users within the same job function or team.

Here are the Standard Profiles Salesforce provides out-of-the-box. These have been set up with pre-selected permissions to save the Administrator a lot of time ticking a lot of checkboxes. Standard Profiles are not editable but can be cloned to tailor to specific business requirements. This cloning process creates a so-called Custom Profile, which is simply another version of the Standard Profile.

Permission Sets are an extension to Profiles, to grant additional permissions for specific job functions, for example the Create Accounts permission.

Some organizations are very restrictive about account creations and thus only allow a small number of users, if not only one, to create them. Hence, this type of permission would not be added to a Profile, but to a Permission Set instead.

Therefore, Permission Sets usually contain only 2-3 permissions and are only created as needed and assigned to individual users at a time.

This means, the Admin can pick from the same pool of SEE and DO permissions but selects only what is not already available to the User through their assigned Profile.

The Profile and Permission Set(s) assigned to an individual user essentially determine their total access.

Permission Set Groups were introduced by Salesforce only a few releases ago, and are used to bundle multiple Permission Sets and assign to selected users. This means, that Administrators no longer have to painstakingly assign Permissions Sets one by one. They can now bundle them into a Permission Set Group and assign the entire group of Permission Sets in one go.

Here’s an example of two types of Users within the same department. You can see that some Permission Sets are the same for both, but then there’s one Permission Set which is only required by the Sales Manager. Therefore, we created two Permission Set Groups based on each user’s job function, added the required Permission Sets (which had been created beforehand) and then assigned to each User as appropriate.

Permission Set Groups can be assigned to multiple users, and that’s exactly why they are so handy. Especially in larger organizations where you may have something like five Sales Managers and 20 Sales Assistants or 20 Sales Representatives, you’ll be saving yourself a lot of time when allocating user permissions.

In summary, up until now you would have done the following:

Set up a Custom Profile containing the minimum permissions, like Read and Edit Accounts (Alert: This part is changing!)
Create Permission Sets by job function – Remember: DON’T add too many permissions into one Permission Set. It’ll be almost impossible to tell what you have added
When you realize you have too many Permission Sets to assign to certain users, you’ll create a Permission Set Group to bundle them and make your life a lot easier

Complexity of Salesforce User Profiles and Permission Sets

What happened so far was that System Administrators created a lot of Custom Profiles to allocate business specific permissions. Then they created a lot of Permission Sets for all those additional permissions of each job function. And then they also started creating a lot of Permission Set Groups. 🤯🤯🤯

There’s suddenly A LOT OF everything!

What does this mean? If you don’t have a smart document that tells you which Profile and which Permission Set does what and which user has what assigned, you’ll be running far far away. 🏃‍♂️

Yes, you can create reports or export a file with Dataloader, but it’ll still be rather difficult to put it all together.

What Will Happen To Salesforce User Profiles

To reduce the amount of Profiles and to add more flexibility to the way you assign or remove user permissions, Salesforce is planning the following changes starting Spring ’26:

👉 Removing most (but not all) user permissions from User Profiles.

IN LIEU, you will need to use Permission Sets and Permission Set Groups, like you already have. But in the future, you’ll manage MOST user permissions through Permission Sets.

Here’s what they will remove from Profiles and ONLY make available through Permission Sets:

👉 ESSENTIALLY, the concept of using Profiles, Permission Sets and Permission Set Groups doesn’t change. Certain permissions like access to Apps, Record Type and Page Layouts will still be managed via Profiles.

BUT, the types of permissions managed through Profiles changes so much so that you will no longer have to create so many Custom Profiles.

Don’t wait for Spring ’26! Start your New BEST PRACTICE already:

Starting a new best practice already will save you time later moving permissions from Profiles to Permission Sets. Here is what this may look like:

Clone the ‘Minimum Access’ Profile and only use to assign Apps, Record Types and Page Layouts for a particular group of users, like Sales Users or Marketing Users. Nothing else!
Name the cloned profile after the role or job function, use a meaningful naming convention
Create Permission Sets by job function – Remember: DON’T add too many permissions into ONE Permission Set. It’ll be almost impossible to tell what you have added. Rather have more Permission Sets with a very precise description
Bundle job function related Permission Sets into a Permission Set Group, give it a meaningful name, and assign to relevant users

FINAL STEP, if not even the first, DOCUMENT what you set up!!! It doesn’t have to be a fancy schmancy paid document service, it can be a simple as a Word document to get you started. BUT PLEASE, write it down.

Our Salesforce Administrator Certification Course takes you through the setup steps and best practices in a logical order. You’ll be a pro in no time!

How Salesforce Will Help You With The Transition

Salesforce is making a plan to help you make the move from User Profiles to Permission Sets. Here is what they have announced so far. As always, refer to the Release Notes for any further updates on these:

Spring ’23 – Salesforce is introducing the ‘User Access Policies’ feature. It will help you ‘migrate’ user permissions based on specific criteria and attributes. HOWEVER, it will be in Beta and only available to orgs with Enterprise and Unlimited Editions (for now).

Summer ’23 – Field Level Security can be switched to Permission Sets. This is ALREADY in BETA. And is planned to become GA (generally available) in Summer ’23. BEWARE: You must have all your Permission Sets sorted and assigned to Users BEFORE you switch this over. Otherwise, it may get ugly…

Spring ’24 – Turn off ability to assign retiring (EOL = end of life) permissions on User Profiles.

Even though Spring ’26 may seem far away, it’ll arrive sooner than you’d like. And then suddenly, you have to migrate hundreds of user profiles.

Start with the New Best Practice mentioned earlier. For example, if there is any new Custom Profile you have been asked to create, don’t create it right away. See if the New Best Practice may actually be a valid alternative already.

Start making a plan for all your Profiles already on how to move the EOL permissions from User Profiles to Permission Sets and Permission Set Groups. Take it step by step, like department by department or job function by job function.

I hope you found this walk-through helpful. Got a question? Please do leave me a comment below! 👏🏻

WHAT ELSE…

We make learning simple with our range of well-structured Salesforce Video Tutorials, downloadable Study Workbooksand realistic Practice Exams.

And if you are brand new to the world of Salesforce, make sure to sign up to our FREE 21-Day Salesforce Beginners Challenge.

Salesforce Basics – Understanding the Salesforce Architecture

Isn’t the Salesforce Architecture the most boring of all Salesforce topics? Not quite! It’s actually pretty fascinating…

Author: Peggy Schael | Salesforce Trainer | WeLearnSalesforce

Salesforce as a Cloud-based Software as a service (SaaS) Platform

Salesforce is a SaaS platform that provides its customers and partners with everything they need, all in one place. And we’re not just talking about customer data management. We’re talking about creating custom applications, automating business processes, and integrating additional functionality, seamlessly.

The Salesforce Multitenant Cloud – Like Living In An Apartment Building

Salesforce brings all their products, like Sales Cloud, Service Cloud, Marketing Cloud and so on, together onto the same platform. The Salesforce platform is built on a multitenant architecture, which allows customers to share resources and data. Salesforce also calls the platform the Multitenant Cloud. Because it’s like an apartment building where the tenants in all the apartments benefit from the network of power supply, storage facilities, facility management tools and so much more. This saves development and maintenance costs.

The Core Architecture of Salesforce And Its Robust Framework

The Salesforce architecture offers a lot more than that. Salesforce Objects and Applications are all coming together on the one and same Lightning Platform. This ensures a seamless integration across all the Salesforce applications as well as applications from other providers that are built on the Lightning platform. All declarative and programmatic tools are shared across the entire platform and make it easy to add new apps or even develop completely new applications.

The Salesforce platform offers a robust framework for data services, artificial intelligence like Einstein, and API integrations. Plus you automatically get release updates three times per year. And since it’s all happening in the cloud, you don’t need to install a thing.

Can You Trust the Salesforce Platform?

And with all of that, one very critical component is most certainly…trust. Salesforce takes data security within its platform very seriously. And not only that, but Salesforce also cares a lot about the customizations you are building into your Salesforce org for all your vital business functions and ensures they run reliably.

Have a look at the Salesforce dedicated trust site trust.salesforce.com. You will find information about compliance, service availability and performance, how data is secured, and more.

The Concept of Metadata Elements

Everything you are building and all the data you are storing on the Salesforce platform is driven by Metadata. Metadata is the data about your data. 🤯 It defines the structure of your fields, page layouts, user profiles, reports, dashboards, etc.

In the example below, the Account Name field represents the metadata, a.k.a. the type of field. This is where the data about the name of the company this contact works for, is stored in.

Metadata is used for different purposes. For example when changes are made in a Sandbox environment and then moved into the Production environment or when data is integrated through external resources. It identifies existing items like fields, page layouts etc. by its metadata.

In our example, the Account Name is actually just the label that appears to the user. The metadata itself is the Field Name or API name. If you changed the label to ‘Company Name’ for example, the metadata or API name would remain unchanged so it can still be identified.

Understanding the Salesforce Architecture isn’t too hard or too boring, right? What do you think? Let me know in the comments!

WHAT ELSE…

This video tutorial is part of our Complete Salesforce Certification Courses. They cover everything from Salesforce Basics to advanced Salesforce features and functionalities every Salesforce professional should know about.

We provide you with different types of study materials, so you can choose what works best for you. This includes well-structured Salesforce Video Tutorials, downloadable Study Workbooks and realistic Practice Exams.

And if you are brand new to the world of Salesforce, I’d recommend to sign up to our FREE 21-Day Salesforce Beginners Challenge.

What You Need To Know About The Salesforce Setup Menu

Salesforce is a powerful platform with many configuration features and setup tools. In order to get the most out of Salesforce, it’s important to understand the options available to you. In this video tutorial, I will walk you through the three main Setup categories and explain what each one is for. Let’s go!

Author: Peggy Schael | Salesforce Trainer | WeLearnSalesforce

Salesforce is a powerful platform with many configuration features and setup tools. In order to get the most out of Salesforce, it’s important to understand the options available to you. The Setup menu contains every single tool you need to configure a Salesforce instance to meet specific business needs.

Where Salesforce Admins Spend Their Day

The Setup is pretty much the engine room to enable the Salesforce user interface settings for optimal performance and usability. Whatever Salesforce Users see in the front end is managed through the backend, the Setup of the platform. It’s the Salesforce Admins go-to place to customize, configure and support a Salesforce instance and its Users.

Become Confident Using the Salesforce Setup Menu

In this video tutorial, I will walk you through the different options in the Setup menu and explain what each one does. You can follow-along from your own Trailhead Playground or Developer Org. Simply click the gear icon ⚙️ in the upper right corner.

VIDEO TUTORIAL WALK-THROUGH SCRIPT:

Go to the gear icon on the top right
You will see the main Setup item
You may see more options such as the Service Setup. This depends on the Salesforce products you have acquired
When you hover over the main Setup item you’ll notice a little expand icon. This will open the Setup menu in a new browser window. So let’s click on it. It will be handy for you to keep the Setup page open separately.
On the Setup Home page you will find some handy quick links at the top.
Click arrow to the right
And below you will find recent pages you have been working on once you get started
On the left is your main Setup menu which comprises of three main categories
The ADMINISTRATION category
This is where you manage your User [USERS >] and their data access [PROFILES]
From here you will do things like adding new users [USERS],
Viewing user details [user “WeLearnSalesforce”], changing passwords and monitor login history
Under Data [DATA>] you will do data exports or set up duplicate management
Under Email you will be creating email templates and a lot more
Under PLATFORM TOOLS this is where most of your customization will happen
You can modify the user interface [OBJECTS & FIELDS] and
Deploy new features [ENVIRONMENTS/DEPLOY]
You can manage your entire data model and create new apps
And if something needs to be coded with programmatic tools [CUSTOM CODE], this is done here too
The third category is the SETTINGS where you will manage your company settings [COMPANY SETTINGS>] such as business hours and fiscal year
You can also view your org’s history [SECURITY>/Setup Audit Trail] and manage your entire security model
You’ll notice that there are a lot of menu and sub-menu items and it might be a bit tricky to quickly find a specific section. That’s where the Quick Find box at the top will come in handy
To the right of the Home tab, you will find the Object Manager tab. You will use the Object Manager to manage page layouts, add fields, create new Custom Objects and so on
The Object Manager [Platform Tools/Objects and Fields/Object Manager] is also available from the main menu. However, since this is a very prominent section, Salesforce has made it easier for you to access it by adding its own tab

Key Setup Pages To Get More Familiar With

Once you start configuring a Salesforce org you will get more and more familiar and confident using the various setup items. There are a few Setup pages you will find yourself going back to regularly:

Company Information: This page gives you an overview of your Salesforce Org and includes the unique org ID, list of licenses, data and file storage.

Users: This is where you will find all User accounts and their details. Popular action items for Salesforce Admins include password resets, creating new Users as well as freezing and deactivating User accounts.

Login History: You will find this section on each User record. It will help you troubleshoot login issues such as incorrect passwords, login IP address, login date, time and more.

Profiles and Permission Sets: These pages are highly relevant to data security and what Users can see and do in a Salesforce org.

Setup Audit Trail: Troubleshooting Setup issues will also become a key element of Salesforce Administration. The Setup Audit Trail provides information about changes in the Setup, including what type, when and by whom the changes were done.

I hope you feel more comfortable with the Setup menu now. Don’t worry you will get a lot of practice throughout our Salesforce Certification course.

Is there any particular Setup area you would like to learn more about? Let me know in the comments!

WHAT ELSE…

And if you are brand new to the world of Salesforce, I’d recommend to sign up to our FREE 21-Day Salesforce Beginners Challenge.

Why You Should Set up a Regular Salesforce Data Backup

Did you know that Salesforce does not automatically create a backup of your Salesforce data? At least not in a way that would allow easy recovery. Any data loss or data corruption in a live Salesforce Org can have a devastating impact if you do not set up a comprehensive data backup and restore mechanism. In this article, we’ll discuss your options of manual and automated solutions.

Author: Peggy Schael | Salesforce Trainer | WeLearnSalesforce

Let me start by asking you this: Do you take photos of your family, friends, hobbies, travel or else? Would you be sad if you lost any of them? For my part, I’d be devastated. Therefore, I regularly create backups of any of my photos, whether I’m taking them with my phone or camera.

What does this have to do with Salesforce? A lot! Because the data stored in a live Salesforce Production Org is critical for customer relationship management, business success, legal compliance and so much more.

This means, if any sensitive or business-critical data is lost and not recoverable, it can have a devastating impact. This is particularly relevant when large amounts of data are impacted.

Data can get lost in many different ways. The most common reasons are:

Salesforce Users overwrite data
Salesforce Users delete records
Salesforce Administrator changes field types
Salesforce Administrator runs data imports

Any of the above can happen by accident or can be deliberate. As the Salesforce Administrator, you have many tools at hand to protect data access, data edits as well as data deletion. However, data loss or data corruption can still happen. In this article, we’ll discuss how you can manage data backups to recover and restore data when required.

Salesforce Data Backup Solutions

Did you know that Salesforce does not automatically create a backup of your Salesforce data? At least not in a way that would allow easy recovery. If you want Salesforce’s help with this process, you will need to install something first, and that’s Salesforce’s Backup and Restore service. It requires quite a few setup steps before it will backup your data and provides a recovery service. Plus, it comes at an additional fee.

Alternatively, you can find backup solutions on AppExchange with a range of highly respected Salesforce Partner Apps that work a charm. Yes, they do come at a cost too. Depending on your Salesforce org’s data capacity, restore process and of course budget, it’s worth checking out these apps. Just search for “backup”:

Source: appexchange.salesforce.com

Meanwhile, what can YOU do already?

While the automated solutions are great, you can already start with the more manual backup solutions Salesforce does provide you with out of the box, included at no additional cost. You can always extend with apps at a later point in time.

These out-of-the-box backup solutions include Report Exports, the Data Export service, and the Data Loader App/Dataloader.io. Let’s go through each to see how and when to use them.

Export Salesforce Data with Reports

Salesforce data is stored on records that belong to various Standard and Custom Objects, such as Accounts, Contacts, Leads, Opportunities, and so on. One of the easiest ways is to create reports for each of these Salesforce Objects and export them into a save place on your company’s server.

PROs: Simple way to create ad-hoc reports relevant for data clean-up processes, before data imports, whenever there’s a limited amount of records involved. Exports to .csv and .xlsx. Can be scheduled for export.

CONs: This is a manual process. You won’t be able to export the entire database. Cannot be used to restore, unless you do a manual re-import under specific considerations.

Export with Data Loader App / Dataloader.io

The Data Loader works similarly to reports in the way that you need to select specific types of records you want to export.

PROs: Automatically stores the export file in a pre-defined location. The export process can be automated using the command line. Exports to .csv, .xlsx and other.

CONs: Requires installation of Data Loader App locally as well as Java Runtime Environment (alternatively use Dataloader.io web service). You need to be familiar with all the above-mentioned tools and processes.

Salesforce Data Export Service

This one is managed right from within your Salesforce Setup menu, no need to install anything. You can choose between weekly or monthly exports (depends on Salesforce Edition). It’s the most comprehensive of the export tools:

PROs: Automatically exports either selected or all data. Can include images, documents, files etc. (Beware file size!)

CONs: Data is only prepared for export. Once the export data is ready, the system will send an email to the Administrator with a link to a .zip file. The zip file is stored within the Salesforce Setup from where it needs to be manually downloaded. And, the .zip file delete’s itself after 48 hours.

The Data Export is really easy to set up and if you can ensure that an Administrator will be around to take care of the .zip file within the 48-hour time frame, then this is certainly a great tool to use.

Final Thoughts

The out-of-the-box backup solutions do not provide out-of-the-box recovery methods. The recovery process is a rather manual process, including tools like the Recycle Bin and Data (Re)Imports. Depending on the volume of data/records involved, remember to take a look at Salesforce’s Backup and Restore service or solutions on the AppExchange.

All of the above is about Salesforce Data, not Metadata. Metadata are the containers that define the type and location of the data, not the data itself. This includes Field Types, Page Layouts, Reports, Validation Rules, and so on. Therefore, if you need a backup, or better a copy, of the Metadata, that’s what Sandboxes are for.

Salesforce Data Backup is part of our Salesforce Administrator Certification Course. Application Management including Sandboxes is covered in our Salesforce Platform App Builder and Salesforce Advanced Administrator Certification Courses.

Let me know in the comments how you manage data backups and which tool you prefer to use.

WHAT ELSE…

We make learning Salesforce simple with our range of well-structured Salesforce Video Tutorials, downloadable Study Workbooks and realistic Practice Exams. Available for Salesforce Administrator, Advanced Administrator, Platform App Builder and more.

All materials are in line with the official Salesforce Certification Exam Outline including regular release updates.

Restriction Rules – Yet Another Data Security Management Tool?

Hell YESSS! Nothing is more important than protecting your customer’s sensitive data you are storing in your Salesforce Org. You can land in prison if you don’t. Ok, I’m being overdramatic, but nevertheless, data protection is a serious topic. So how about we break down the entire model and see how the Restriction Rules fit in? Let’s go!

Hell YESSS! Nothing is more important than protecting your customer’s sensitive data you are storing in your Salesforce Org. You can land in prison if you don’t. Ok, I’m being overdramatic, but nevertheless, data protection is a serious topic. And your data security toolset just got a new addition. 🤯

Whether you are a new Admin, experienced Admin, App Builder, Product Owner or otherwise involved with the Salesforce Setup, understanding how to protect sensitive data stored in Salesforce is probably one of the most important aspects of setting up and managing a Salesforce Org.

We all know that the Data Security Model is already rather complex and now you have been given yet another tool. So how about we break down the entire model and see how the Restriction Rules fit in? Let’s go!

Salesforce Data Security Model & Where Restriction Rules Fit In

Now, as I mentioned above, the Data Security Model is complex and consists of many layers. In general, we have four layers/levels:

Organization-level = This is where you manage the first entry point of a Salesforce User, their login to the system. This includes things like IP Ranges, Login Hours, Password Policy, and so on. Anything that authenticates the User BEFORE they get access to Salesforce.

Object-level = This is what the User will have access to AFTER they successfully logged in. All Salesforce data is stored on Salesforce records that belong to Salesforce Objects. Hence, you will typically use tools like User Profiles, Permission Sets, and Permission Set Groups to manage access to Salesforce Objects.

Record-level = This is where things really start to get interesting with managing access to records that contain all that sensitive or not-to-sensitive data. Therefore, you want to be very careful which records Users should have access to. The baseline tools you’ll have available, are Organization-Wide Defaults (OWD), Role Hierarchy, Sharing Rules, Team Sharing, and Manual Sharing. PLUS, you guessed it, Restriction Rules.

Record-level sharing is the most complex of all our four layers, so here is how they are built up:

Field-level = Is all about managing access to the individual data types (= fields) stored on Salesforce records. You can choose between No access, Read access or Read/Write access.

Now that you know WHERE Restriction Rules fit in, we’ll discuss HOW they work.

HOW Do Salesforce Restriction Rules Work

While your baseline Record-level Sharing Model pretty much opens up access to records, Restriction Rules take away access. In other words, they limit the User’s record access to a sub-set of records they used to have access to. It’s like setting a permanent filter to display only pre-defined records. Why would you need to do that? Good question! We’ll look at some examples shortly.

Now, Restriction Rules can also be used for Objects that do not support any or some of the Record-level Sharing tools.

Let’s look at some examples for both scenarios:

An example where Restriction Rules limit access:

Let’s say you have a Recruiting Team, of which the Recruiting Assistants have access to Positions of the status “Open”. They have hired a Junior Recruiting Assistant, to support with open Positions which need to be filled by the end of the month.

We’re assuming the OWDs for Position is set to “Private”, a Role Hierarchy has been set up including the Role “Recruiting Assistant”, and a Sharing Rule is in place which shares all open Positions with the Recruiting Assistant Role. This Role is also assigned to the Junior Recruiting Assistant. What now?

Well, the Junior Recruiting Assistant has been assigned the Title “Junior Recruiting Assistant” on the corresponding User Record. And this is where we bring in the Restriction Rule. You will use the Restriction Rule to only display open Positions with a Close Date of the current end of the month, to Users with the Title “Junior Recruiting Assistant”.

This may look like this:

The result is this: The Junior Recruiting Assistant already had access to all open Positions because of the Sharing Rule. Of these open Positions, the Restriction Rule limits access to open Positions that contain the date of the current end of month.

Why could you not solve this with a Sharing Rule? Because Sharing Rules don’t support sharing based on User Criteria which are not Role-related. You could use a workaround though, like adding another Role “Junior Recruiting Assistant” to the Role Hierarchy and using this to create a secondary Sharing Rule. However, this makes the Role Hierarchy more complex and will have additional implications on other Sharing Rules, Reports, etc.

As a Salesforce Administrator, you always want to find the least complex but most effective solution. 🤓 Now, you have one, and that is Restriction Rules.

An example where Restriction Rules are the only option:

We’ll use the “Activity” Object which does not support Sharing Rules.

First up, the Object “Activity” relates to “Tasks” and “Events”, and supports OWDs such as “Private” and “Controlled by Parent”. If we chose “Controlled by Parent”, Users who have access to the associated Parent record (what you select in the “Related To” field), maybe “Account”, can see ALL tasks and events of the Accounts they have access to. You can’t restrict access to certain Tasks or Events of those Accounts, even if you selected the OWD “Private”. The latter would limit access to Tasks/Events a User owns. You wouldn’t be able to open up access to specific Tasks/Events Users do not own, because Sharing Rules are not supported.

How do we fix this? Exactly, with Restriction Rules. Let’s look at a more specific example:

Let’s say you wanted Users of the Marketing Department to only have access to Tasks which have been marked as “Marketing Follow-up”. Again, we’ll use the OWD “Controlled by Parent” as the baseline setting.

Next, we’ll go to the Object Manager and select “Task” and then select “Restriction Rules”. From here, you’ll determine a meaningful Rule Name, specify the User Criteria (like the Department field on the User Record) and then specify the Record Criteria (like the checkbox field “Marketing Follow-up”).

This may look like this:

The result will be: The Marketing Users used to have access to all Tasks of their Accounts because of the OWD “Controlled by Parent” on the Activity Object, but now get a limited view to Tasks marked as “Marketing Follow-up” because of the Restriction Rule.

What Else You Need To Know About Salesforce Restriction Rules

Restriction Rules have only been made GA (Generally Available) in Salesforce’s Winter’22 Release. They still have a number of limitations around where and how you can use them. As always, keep an eye on the Release Notes for updates around the capabilities of Restriction Rules.

Here are some of the key items you currently need to consider before you set up Restriction Rules:

Only support Custom Objects and the following Standard Objects: Contracts, Events, Tasks, Time Sheets and Time Sheet Entries
Enterprise and Developer Editions only support up to 2 Restriction Rules per Object, Performance and Unlimited Editions up to 5
One Restriction Rule per Object per User
User Criteria and Record Criteria are limited to a small number of data types (e.g. boolean, date, string)
You can’t add more than one User criteria or more than one Record Criteria
The Operator is limited to “Equals”
Recently Viewed List Views still show records a User may have previously had access to, however when a User attempts to open the record, they will get an error

Make sure to familiarize yourself with the full list of considerations: https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule_considerations.htm&type=5

While the capabilities of Restriction Rules are still rather limited, they already open up great opportunities for System Administrators. They have been put in place for a reason. 🤓

Let me know in the comments if you have been using Restriction Rules and how they have been working for you.

If you want to learn more about Salesforce’s Data Security Model, it’s part of our Salesforce Administrator Certification Course. You can sign up for a Free Preview first to get to know our Video Tutorials, Study Workbooks, and Practice Exams.