Customer Data - the crown jewel of the modern enterprise
Without a doubt, customer data is some of the most important, sensitive, and business-critical data that any enterprise might possess. Organizations are entrusted with their customers’ most sensitive information to provide services, deliver solutions, or simply to engage. In many cases, even before someone formally becomes a customer - the exchange of data has started including PII such as email addresses, phone numbers, and location information.
For most enterprises, this data accumulates within Customer Relationship Management (CRM) and Customer Service Management (CSM) systems counting in the millions (or even billions) of records. It’s no doubt then, that these systems are commonly the first target for data exfiltration by malicious users, both inside-and-out of the organization. Verizon’s Data Breach Investigation Report (DBIR) 2023 lists the ‘personal data’ of customers, partners, and employees as the most breached data type in more than 50% of all breaches. The report goes on to describe it as “the one that usually gets companies the most in trouble with regulators, as more and more privacy related laws are passed around the world”.
Bringing People Together Changes Everything
With all of this data, organizations turn to gigantic cloud platforms to enable storage and management of this sensitive data at scale. Salesforce is undoubtedly the market leader in providing enterprises.
From tracking leads and opportunities; to being the central repository for all interactions with an established customer through their journey; to renewals, support, and upsell - Salesforce is a complete platform to manage customer interactions. That’s a lot of data and a wide range of data types to store in one place. It also means that a variety of users across departments, functions, and locations will need to be able to access data in Salesforce. Not to mention the complexity that is introduced with an extended workforce that may include partners, contractors, or seasonal employees.
So where does that leave today’s enterprise? SGNL customers explain that the centralization of so many facets of customer data, of which individual parts for a given customer may need to be accessed in Salesforce by dozens or even thousands of employees, creates a unique challenge in balancing security and access. And for organizations striving for a zero-trust architecture - this understandably makes identity, security, and executive teams a little uncomfortable.
Salesforce has a robust set of native authorization capabilities. The system has evolved over decades to accommodate the broad range of use-cases an enterprise might need. It provides the means to statically assign a given user (or set of users) a set of permissions that can get them access to the things they need. For most enterprises though, these permissions grant more access than is needed by individuals to successfully do their job.
So why is that?
The reality is that creating granular permissions directly in Salesforce is hard to build and difficult to maintain. For enterprises that have made the upfront investment, they’re often either spending significant time, resources, and money to constantly update permissions within the platform or frequently getting in the way of the business teams trying to engage with their customers.
What’s an Enterprise to do?
Well. I’m here to tell you that all hope is not lost. We have been working closely with our customers and partners to develop an out-of-the-box solution that enables dynamic, continuous, and centralized access management for Salesforce. Our approach doesn’t involve weeks, months, or years of implementation; handles access management at the individual record-level; and will actively reduce the burden on your Support, Identity, and Business Ops teams to manage Salesforce.
SGNL for Salesforce is our new, guided experience that gets context-based access management for Salesforce set up and protecting Salesforce in the same day.
With SGNL for Salesforce, create continuously evaluated policies in minutes that determine when users can access specific records. These dynamic policies can be based on real-time context about a user as well as business context from the various business systems in the enterprise (e.g. citizenship, desk location, ticket assignment, etc) and more.
Let me take you through the steps to get that going.
Getting Started with SGNL for Salesforce
Getting started with SGNL for Salesforce is simple. In this first release, we are providing out-of-the-box support for three of the Salesforce access management use cases requested most by our customers:
- Restricting Account objects based on Segment
- Restricting Account objects based on Geographic Region
- Restricting Case objects based on Geographic Region
SGNL supports many other use cases, including dynamic access to a range of other Salesforce Object types, as well as field-level control within Salesforce objects. We know that your Salesforce is customized, and you can customize your SGNL for Salesforce policies too! You can easily modify the default configuration or create an entirely custom use case directly in the SGNL for Salesforce configuration using both our human-readable Policy Editor or directly in JSON.
As a first step, we’ll connect your Salesforce organization to SGNL. Integrating your Salesforce to SGNL adds your Salesforce as a System of Record in SGNL. Systems of Record are connected apps and systems whose data becomes business context in policies you create. Integrating your Salesforce to SGNL also makes Salesforce a Protected System in SGNL, which means you can write policies to protect this system.
To learn more about how to connect your Salesforce to SGNL, read more in our support documentation.
Selecting your Use-Cases
You’re now ready to configure how SGNL will protect Salesforce with continuous access management policies. You’ll be automatically guided to the right place in SGNL to get started customizing the configuration for your use-case.
We’re going to keep it simple for now and classify our Account Objects in Salesforce, based on the Salesforce Segment that they belong to. Classifications can be easily modified to enable the configuration to be tuned exactly to the needs of your organization.
When you click Save, you’re all done configuring the integration. It’s now time to select or create the policies you want applied.
Creating and Managing Policy
You’ve now created a basic integration between Salesforce and SGNL, and the bulk of the heavy-lifting has been completed by the SGNL for Salesforce Configuration experience.
The next step is actually setting up policies for your organization in SGNL. Who, and under what circumstances, should someone be able to access a specific category of Accounts, Cases, or the Objects you specified?
With SGNL, access management policy is simple to understand and create, informed by contextual and dynamic data, and built with building blocks called Snippets that can be reused across policies and systems.
The above policy allows only people with the Salesforce Role of ‘Account Executive’ to get access to Accounts when they are assigned to that customer segment.
This policy immediately adds value to any Salesforce deployment, but also changes as a user’s Role, or Customer Segment assignments change. With SGNL policies proactively protecting assets using dynamic data Snippets, access management decisions will immediately augment who can access a specific customer account – gone are the days of having to manually update group membership, rules, or roles.
When we login to Salesforce as one of our Account Executives, we can see the difference. The Account Executive user previously had access to every Account in Salesforce. After enabling SGNL policies , the Account Executive is seeing only the Customer Accounts for the Segment in which they work.
So What’s Next?
We’ve now added dynamic, contextually-informed access management to Salesforce, ensuring that the right users get the right access when they need it.
With SGNL, teams can ensure that right access by bringing together business context from all the various systems that exist in their modern enterprise and combine that into dynamic, understandable policies - not just relying on Roles in Salesforce.
With that in mind, you can bring additional Systems of Record into your SGNL Client to enable even more expressive, and context-rich policies to be created.
In the SGNL Client below, I’ve added Workday (often the authoritative source for end-user position, department, and title information) and Intune (the authoritative source for device compliance, health, and state). In doing so, I can now update my policy to include that rich, and real-time context:
With Workday and Intune added, we can now have a far more expressive policy, and incorporate that system data without passing employee PII into additional and unnecessary systems. Here, we’re incorporating Workday data for the user’s role and position, Salesforce data to define active customers and their segment, and Intune to ensure that the user’s device and account are in a healthy state prior to accessing sensitive data. SGNL will evaluate a user’s access request against all attributes included in this policy continuously, ensuring that your users always have the right access at the right time, based on user and business context.
SGNL for Salesforce and Beyond
In this blog, we’ve looked at SGNL for Salesforce and how dynamic, context-rich policies can grant the right access at the right time. If you’re an organization using Salesforce and feeling the challenges of access management to comply with customer, regulatory, and compliance requirements - reach out so that we can get you started with our new configuration experience.
And access management with SGNL doesn’t end with Salesforce. SGNL can also provide centralized, continuous access management for tens of other off-the-shelf applications and services, as well as internally built applications. With SGNL teams can centralize context-informed access management and decision audit logs into one robust and easy-to-scale system.