Human services organizations commonly need to limit data access for staff members to their specific caseload and programs. Limiting this access provides necessary privacy safeguards and simplifies data management by allowing staff to see only the records they need.
As a nonprofit Salesforce admin, you may have already set up some basic privacy settings and restrictions organization-wide. But if your organization’s security requirements have gotten more complex, there may be a cleaner, more effective way to manage access to Salesforce records at the program level.
What might program-level security access look like in Salesforce? Let’s look at a scenario for a recent client of ours: Foundation for Blind Children.
The mission of the Foundation for Blind Children (FBC) is to provide education, tools, and services that enable all persons with vision loss to achieve greater independence.
Problem to Solve: Limit record access to ensure data accuracy and privacy.
FBC employs providers to instruct blind and visually impaired students on skills like orientation and mobility, reading braille, using assistive technology, and building skills for daily living.
State-run Arizona Rehabilitation Services issues reimbursement for providers’ hours with each adult student who is enrolled in FBC’s Adult Comprehensive program (with some authorization requirements).
This means it’s important for providers to track their time with students accurately so that FBC can bill correctly. Providers needed a simple way to track the time they spent with their students, and only their students.
To accomplish the goal of giving providers a simple and straightforward way to find their clients and enter time, FBC restricted data access at the Salesforce organizational level and implemented sharing in their organization. This way, providers didn’t even have the permissions to enter time for the wrong client or the wrong service.
What does that setup look like specifically? Read on!
The Solution: Share the records providers need. Hide the records providers don’t need.
Providers need access to the students who are enrolled in their program. So first, we laid the program enrollment foundations in Salesforce.
We built out an architecture that enabled FBC’s program admins to enroll students into their programs, so that providers could track time.
Using this architecture, the Adult Comprehensive program admin creates a program enrollment record for a student. This record links the student’s contact record to the Adult Comprehensive program record.
A program admin for FBC’s Educational Services Department will do the same thing for their program’s students.
Providers can then log in to Salesforce and pull a list of enrollments filtered to their specific program, select the enrollment for the student they want to track time on, and create a time entry record to log their hours.
FBC wanted to limit access to program enrollments so providers could only track time for their students. This way if a provider accidentally searched for a student that wasn’t in their program, they wouldn’t have a way to add a time entry to the wrong student. To accomplish this, FBC needed to restrict access to program enrollments by program. So we set that up next.
We’ll cover the nitty-gritty Salesforce details for both sharing and restricting access in the next section.
How We Built the Sharing Model (and How it Could Work In Your Org):
- Public Groups
- OWDs (Organization-Wide Defaults)
- Criteria-Based Sharing Rules
First we trained FBC’s Salesforce admin to set up public groups that determine which providers get access to which program enrollments.
The admin set up a public group for each program department, then added each provider to the group for their program. (These public groups that the admin set up will come in later for sharing out records.)
Now that we have public groups set up, we’ve set the foundation for our sharing model. Next, we set the organization-wide default (OWD) sharing on the program enrollment object to private.
By default, a private OWD restricts any access to records a user doesn’t own. Many nonprofits don’t necessarily need to lock down program enrollment data if there isn’t some specific reason to do so. But if you have a requirement to restrict access to one group of users, you need to restrict access for everyone at the OWD level and then incrementally share records out.
There are a number of ways to share records in Salesforce. Because FBC providers needed access to records based on the program’s department (not based on who their manager is, like with the role hierarchy**) we decided to implement criteria-based sharing rules.
If your organization’s sharing requirements are strictly based on managers being able to see their direct reports’ records, your basic owner-based sharing rules will do just fine, but if your org is a bit more complex, criteria-based sharing rules will give you a lot more flexibility.
These rules let an organization share a subset of private records (in this case, program enrollments) to a group of users based on field criteria. For FBC, we created a criteria-based sharing rule for each public group that looked at the department picklist on the program enrollment. This means that regardless of who created FBC’s program enrollments, our sharing rule will grant public group members access to the record, provided it has the right department filled in the record.
Public Groups vs. Role Hierarchy in Sharing
If you’re a long-time admin, you’re most likely familiar with the Salesforce role hierarchy, which can be used to manage permission settings automatically up the management hierarchy. You could even set up departments in your role hierarchy and use sharing rules to share records to department members by role. So why did we use public groups instead of the role hierarchy?
Good question! The difference between public groups and the role hierarchy is a user can only have one role, but a user can be a member of multiple public groups.
Why is that important? Let’s say that during the school year a provider at FBC works with children in the Educational Services Department (ESD) during the day, but provides instruction to adults (ATS) in the evening. If we implemented the role hierarchy, a Salesforce admin would need to switch the provider’s role from the ESD department to the ATS department each day in order to share the appropriate records with that instructor.
Well, that’s just silly! By using public groups in our criteria-based sharing rules, we can add the same provider to both public groups, so the instructor always has access to the records they need.
Sharing and User Management After Setup
Now that we have public groups for users and criteria-based sharing rules to assign access to records, how does the Salesforce admin maintain this sharing model moving forward?
It’s pretty straightforward. Any time a new provider comes on board, that user will need to be added to the public group for their department. Voila! That user has access to that department’s program enrollments.
Should FBC decide to add a new department, the Salesforce admin will create a new public group for that department and add an additional criteria-based sharing rule to share out that department’s program enrollment records.
Summary
Implementing public groups and sharing rules in Salesforce allowed FBC to restrict access to client records without overcomplicating or overbuilding their system. This makes entering time easier for providers and ensures that FBC program admins and managers can trust the data in their reports when billing for reimbursement.
Everybody wins when sharing is implemented thoughtfully. FBC’s case provides Salesforce security insights that you can apply in your own organization to effectively share just the right content and no more.