User Management and Security

Welcome to Chapter 6. You are getting closer to the halfway point of the book. In the previous chapter, you learned about the differences between standard, custom, junction, and external objects, and their application in the system. I’m sure this has helped you understand the most important aspects of Salesforce’s structure. Now that we have the structure, let’s take a closer look at users and their access. After all, the system would be meaningless without its users. It’s like a city without residents or Coca-Cola without bubbles. Certain elements are indispensable. So, in this chapter, we’ll take you on a wonderful journey through user management and all the elements related to their access.

I would like you to pay special attention in this chapter to how you can grant specific access to your users, and how to revoke it – you could say that you are somewhat the lord and master of your Salesforce org. Here is...

User management

Do you remember how Dr. Frankenstein created his monster? Just like him, we will create our first user (don’t worry; it will be much less macabre than in the novel). During your work in this ecosystem, you will often encounter requests to create a new user. When setting up a new user, the request should include certain significant elements such as the following:

• First/last name
• Email address
• Username
• License
• Profile

These elements are extremely important; without them, users can’t be created and in the later stage access the system. Creating a new user can be compared to setting up your own account in a new online store. Just as there, you need to provide details such as first/last name, email address, and phone number. Often, systems also ask for a username.

And here, let’s pause for a moment. I want to draw your attention to one important element. In Salesforce, your username must be unique, meaning it can’...

Password management

This section can be summarized by two characteristics of passwords: hard to break and containing as many different types of characters as possible. But you probably already know that passwords such as 12345 or QWERTY are not good choices. In general, it seems that the silliest passwords, such as 1L1k3P4nK3ke$ (I like pancakes), are the hardest to crack. Unfortunately, we don’t always have control over the passwords our users set... or do we? Here and now, I want to make you aware that we can force them into certain password requirements. To do this, go to Setup, and in the quick find box, please enter password policies and select the entry that appears. Here is a list of settings that will help you manage passwords using Password Policies:

• User passwords expire in: This setting allows us to determine the length of time a password is set for. In the list, we have options ranging from 30 days to Never expires.
• Enforce password history (How I dislike...

Controlling system access

Once we have users and they have their passwords, in theory, we can say that the system can start to live. Using the earlier example of a city and its residents, our users can start wandering through our system, visiting its nooks and crannies, creating records, and admiring dashboards. But they also need to sometimes leave this digital city and relax amid the real chirping of birds, the sound of water in the nearest stream, and the warm rays of the sun on their skin... Oh, forgive me – I got lost in thought looking out the window at the snowflakes swirling in the wind. But returning to the topic of mandatory time off from Salesforce, many companies have their policies, a set of rules that apply to employees at a certain level.

Sometimes companies simply do not want employees to access Salesforce data outside of the workplace, which may be due to data security reasons or simply because the office is located in a certain place and the company does...

Profiles, roles, and permission sets

If we already have a user, let us give them access to certain doors that were previously closed to them. Therefore, in this section, we will deal with profiles, roles, and permission sets. Let me start with the first one. Long, long ago, Salesforce created great software for database management. When users started browsing all the records, one of them stumbled upon the salaries of other employees. This is, of course, a fictional example, but I think such situations could have been quite common. Whenever I start a conversation with a client, I mention such examples; they always spark the imagination, and we start discussing access.

Profiles in Salesforce are a key element in ensuring user access and security. Forgive me for spoiling a later part of the text – this may soon change. For now, profiles maintain all elements related to access; thanks to them, you can grant or revoke the possibility of entering records of a given object. Can...

Sharing settings and organization-wide defaults

In the previous section of this chapter, we learned how Salesforce profiles, roles, and permission sets can influence Salesforce security related to Salesforce objects and their features. In this section, we will learn about security related to Salesforce data sharing. To do this, we will deep dive into the world feature called Sharing Settings to discover its two core features called Organization-Wide Default (often shortened to OWD) and Sharing Rules. Both features are connected and together create the core on which the Salesforce security is built. Let’s see how those features work in detail.

Organization-Wide Default

From the previous section of this paragraph, we understood that Salesforce profiles and permission sets are responsible for giving access to Salesforce objects. So, profiles and permission sets are controlling this if I see the Lead tab, Account tab, Opportunity tab, or any other standard or custom tab. But...

Field-level security

Field-level security is a straightforward concept that enhances security beyond object and record access. Put simply, it regulates field visibility for users. By employing field-level security, you can dictate whether users with particular Salesforce profiles or permission sets should have access to specific fields or not.

Let’s see how this works in practice. Let’s modify the field access on the Account object:

1. Navigate to Setup and search for Field Accessibility.
2. Choose the Account object.
3. Choose the View by Fields option.
4. Choose a field. For example, pick the Phone field
5. Choose the profile that you want to update; for example, Read Only. Click the link in the Field Access column.

   Edit the Field-Level Security settings. Let’s make the Phone field not visible for the user with the Read Only profile. Just make sure that the Visible checkbox is unchecked.

6. Save your settings.

Please look at the following...

Login policies and MFA

In the previous section, we discovered how to secure the data internally so that the proper user who has already access to your org could see the proper data and not more than they should. Now, let’s see how to secure access to the org itself. In this section, we will handle the security topics related to Salesforce user’s MFA. This topic is very important, and each company should be aware of it. As Stéphane Nappo, Cisco Security Officer, once said: “It takes 20 years to build a reputation and a few minutes of cyber incident to ruin it.” Let’s now see how Salesforce creates a secure org environment using MFA.

MFA stands as a straightforward yet highly efficient method to fortify login security, offering robust protection for your business and data against potential security threats. MFA involves a process necessitating users to confirm their identity through two or more verification steps before gaining access to their...

Summary

In this chapter, users delved into pivotal elements of Salesforce security and access control.

The exploration began with an in-depth look at sharing settings, shedding light on the crucial role played by organization-wide defaults and sharing rules. Users gained a profound understanding of how these settings dictate record access within an organization. Particularly emphasized was their role in horizontal data sharing among different teams or groups, enriching the comprehension of data visibility.

Field-level security emerged as a critical aspect, unveiling its significance in managing field visibility and editability. Users discerned the nuanced differences between controlling field access at the Profile level versus the Page Layout level, empowering them to exercise tighter control over sensitive data.

The chapter progressed to focus on login policies and MFA, exploring strategies to fortify user authentication and ensure secure access to Salesforce platforms. This...