Salesforce earned its place as a market-leading customer relationship management (CRM) platform, combining a package not only for CRM but everyday operations as well.
However, with great power comes great responsibility, and given that everyday operations are often packed with sensitive data, administrators should prioritize their customers’ data security whenever possible. The overwhelming majority of data breaches come from human error, but careful permissions management can limit the chances that such mistakes happen at all.
What are Salesforce objects?
Objects are the core components of Salesforce. They organize and store packets of data that represent customers, products, orders, and any other aspect of doing business. They can also relate to one another and have master-detail hierarchical relationships.
In turn, objects contain (and are made of) fields that define data storage types, including but not limited to plaintext, dates, and amounts, thus forming the core of a business’s day-to-day functions. Salesforce system administrators should, therefore, treat access to them with care.
Careful permissions can ensure that only the proper users can access or edit the data within. Experts call such an approach to access object-level security. In Salesforce, it acts as a fine, detailed line of defense that sits at the forefront of a business’s internal security policy.
What sets object-level security apart?
Object-level security in Salesforce and its proper implementation keeps users or groups of users away from information that is irrelevant to their job or that could pose a threat to daily operations if placed in the wrong hands.
While it might be simpler for a company to give all of its users access to every Salesforce object, it increases the chance of mistakes. A user in a different department could edit the wrong field, triggering a cascade of errors that can take weeks or even months to correct.
In addition, and as you might presume, object-level security also offers safety benefits. For instance, if a hacker manages to compromise an employee account, they would only be able to access the Salesforce objects available to that employee. As such, an object-level approach to security creates an automatic quarantine without requiring any action from cybersecurity teams.
Profiles
When a Salesforce administrator creates a profile, they create a set of permissions, based on a template, that restrict the actions a user can take and upon which objects they can take said actions. Some profiles can only access certain object types, while others can access an entire object but only edit a few of its fields relevant to their job description.
Salesforce profiles create pre-built permission sets that administrators can apply to new users. They also make control easier, as instead of editing every user profile one by one, the administrator can make a few small changes to a single profile template. Thanks to Salesforce’s automatic profile control systems, the change will spread to the group of users under that template, streamlining the update and policy revision process.
What do user profiles control?
User profiles control and record the types of objects that users can access and edit, as well as their ability to access and edit certain fields within those objects. They also determine the apps the users can access and how they load them, as well as the hours, locations, and IP ranges a user can use to log in. These security measures help block hackers in different locations and time zones before they access and alter critical information.
Common profile types
While Salesforce profiles are completely customizable, common profile types include the following:
- Standard users, who can read, edit, and delete selected objects
- Read-only users, who can only access objects, not edit or delete them
- System administrators, who can access other profiles and all objects
These three general profile types act as the basic building blocks for customized templates. Instead of altering the built-in standard template, administrators can create a new one that better fits their organization's needs as many times as necessary.
Permissions
Administrators can only assign one profile to a user at a time, but permission sets help admins customize existing profiles for the needs of individual positions, especially since users can have as many permission sets as they need.
If a department or special team needs to access an object not available in their profile, the administrator can grant additional permissions and apply that set only to those employees. It is a case-by-case approach that provides even more of the customizability and flexibility that Salesforce is known for.
Permissions can also allow users temporary access to objects to users, and administrators can also delete permission sets once they fulfill their purpose or modify them as the needs of the situation evolve. Either way, the flexibility at hand closes up the potential threats that modifications to the entire profile set can expose.
Records
In Salesforce, record access determines which individual records users can view and edit in each object they have access to in their profile.
Record-level security, as its name implies, limits user access to specific record types. For example, an enterprise that partners with many businesses won’t need each of its employees with partner-object permissions to access every record in that object.
As outlined in Salesforce’s Trailhead module, on record-level security, you can control record-level access in four ways:
- Org-wide defaults specify the default level of access users have to each other’s records.
- Role hierarchies ensure managers have access to the same records as their subordinates. Each role in the hierarchy represents a level of data access that a user or group of users needs.
- Sharing rules are automatic exceptions to org-wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see.
- Manual sharing lets record owners give read and edit permissions to users who might not have access to the record any other way.
Fields
Last but not least, field-level permissions limit which users can access fields within the objects they can access. For example, customer representatives may only be able to edit contact and billing information and read more detailed histories, while CRM managers can access and edit everything. Setting up field limitations means your employees can change the information they need without threatening the rest.
Simplify object-level security with Own
With Own Secure’s Who Sees What feature, you can quickly search your Salesforce data across object, records, and users lenses to understand precisely why Salesforce users have read, edit, deletion, or export permissions. Learn more here or request a demo below.
