Why Data Security Starts With Salesforce

Note: We’re proud to present this guest post on from Nullafi, an award-winning SaaS company. If you’re a Strongpoint partner and you’d like to be featured in our blog, reach out to marketing@strongpoint.io for more info. 

Customers want digital experiences that make their lives easier and wallets lighter. However, they have a complicated relationship with their personal data. They don’t trust most companies, but they also won’t stop sharing information with them. 

Salesforce’s 2020 State of the Connected Customer report backs this up, noting that:

  • 47% feel most companies don’t use personal information to benefit the customer
  • 63% feel most companies aren’t transparent about how they use personal information
  • 61% feel like they’ve lost control over how companies use personal information

Businesses start every new relationship having to earn their customers’ trust. They need to prove that they’re protecting the information they collect from external and insider threats, and that they’re being transparent about how they use it. Most importantly, this has to begin with the first interaction, and continue while the prospect moves through the sales cycle. 

Salesforce Security Best Practices

If you run Salesforce as your CRM, it’s very likely to be the first place that customer information enters — whether it’s an email submitted through an online form, a purchase, or contact info collected at a trade show. 

The good news is that, on its own, Salesforce is inherently a very secure platform. The problem is that, even with this excellent base, many organizations still struggle to manage Salesforce security, privacy and compliance. Why is that?

Salesforce Security

Data security across application ecosystems relies on enforcing the principle of least privilege, which means granting users the least amount of data and resource access they need to fulfill their job functions. 

If you can’t compare user permissions between applications, you need to configure each application individually. As you integrate more applications with your Salesforce instance, your IT department can become overwhelmed trying to configure each one individually. 

Worse, maintaining best practices around Salesforce security and data access isn’t a “once and done” process. People move within the organization or leave. If you’re managing each application individually, then your IT team needs to make sure that for each application, they either change the access when someone moves or revoke it when someone leaves. 

Salesforce Data Privacy

Data privacy is even more challenging. Like data security, in Salesforce, setting access controls is the first step. However, just because users have access to a resource or application doesn’t mean they need to see all the information. 

For example, your sales team needs to see a prospect’s name and email address — but not necessarily the bank account number. Meanwhile, Billing might need to see a bank account number — but not everyone in that department.

Not only does the IT team need to set controls that limit access to Salesforce, it also needs to maintain Object- and field-level security in Salesforce — in other words, what each of the user types within the departments can view. 

If you can’t set global access permissions, then managing data privacy becomes even more burdensome. 


Now comes the biggest hurdle of all: documenting your activities to meet increasingly strict compliance requirements. If you’re accepting payments and managing consumer data, you might need to comply with the following:

  • Payment Card Industry Data Security Standard (PCI DSS)
  • California Privacy Rights Act (CPRA)
  • General Data Protection Regulation (GDPR)

To prove compliance, you need to have documented, repeatable Salesforce security processes. Making sure that no one can see data that they don’t need to see is hard enough. You also need to prove that you can detect changes to access and identify changes to critical data.

Doing all of this manually or within each application becomes time-consuming. Often, manual processes create human error risk which can lead to compliance violations and fines. (Strongpoint has an excellent tool for automating this process and eliminating the potential for error — read about it here.)

Case Study: Salesforce and Quickbooks

Getting back to the principle of least privilege, one challenge we see frequently is that it’s difficult to compare the different ways SaaS applications define access. Every application uses a different format and definition for data types, user permissions and activity logs.

For example, it’s not always obvious which Quickbooks Areas relate to data categories in Salesforce, making it hard to maintain the kind of tight controls around data your customers require. 

In Salesforce, you can use permission sets to define the level of access for individuals or a group of users:

  • Object-level security: Object-level permissions prevent users from seeing, creating, editing or deleting a particular type of Object, like a lead or opportunity.
  • Field-level security: Salesforce's field-level security permissions control whether users have read-only, edit or delete access for values within a particular field on an Object.
  • Record-level: Record-level permissions grant access to some Object records but not others.

In Quickbooks, you can set the following permissions:

  • Areas: Quickbook Areas are groups of related workflows or tasks, like Accounting, Banking, Customers & Receivables, Lists and Reports
    • Activities: Quickbook Activities are defined tasks within an area.
    • Access levels: Quickbook Access Levels define how users interact with data across Areas and Activities:
      • None: Users have no access to an Area or Activity
  • Full: Users have complete view, create modify, delete and print access
    • View: Users can view data related to a selected item
    • Create: Users can create new activities, entries, or transactions

Integrating Quickbooks and Salesforce allows you to automatically download opportunities and draft invoices directly from the Salesforce data. However, unless Object-, Field- and Record-level permissions are perfectly mapped to their Quickbooks counterparts, you might be accidentally exposing PII or other sensitive data to someone who shouldn’t have access to it — a clear violation of customer trust.  

And of course, Quickbooks is a relatively straightforward accounting program — when a business grows and moves up to a proper ERP like NetSuite, the problem only gets more complicated.

Standardizing Field-Level Salesforce Security With Nullafi

Nullafi simplifies the process of setting access controls and field-level security in Salesforce and integrated applications. Our platform makes it easy for users to define access policies with regular language instead of requiring complex terms. 

Additionally, we do all the background work for you so that you can set access according to the principle of least privilege across your entire application ecosystem. Our technology compares and standardizes access so that you can protect data security and privacy.

If you need to prove compliance, Nullafi helps with that, too. Our platform lets you search records so that you can trace user access in real-time, identifying the user, IP address, and resource. 

Customers care about how you protect their information, and you care about your customers. Protecting data privacy and security is the foundation of customer trust for stronger relationships.