Many nonprofits operate at a broad geographic scale. Local staff are focused solely on their particular location, while managers and senior leadership need to view information at many levels. What’s the right Salesforce security model to support these separate requirements?
We recently worked with multiple national housing nonprofits and used Salesforce’s Enterprise Territory Management to provide a manageable and flexible security model to meet their data visibility needs.
In this post, we’ll focus on Project Access (PA). Project Access is contracted to provide health, education, and employment services to affordable housing communities. Resident service coordinators (RSCs) work at their ~80 affordable housing sites. They use the Program Management Module (PMM) to track their resident services work. Their data visibility goals were:
- RSCs who work at a single location only see that location’s data.
- RSCs who frequently support sites in other regions can easily view and manage client data across regions.
- Monitoring and evaluation staff can report at many levels including nationally and regionally.
Let’s compare and contrast some of the relevant Salesforce features in Project Access’ implementation. We partnered with them to upgrade their security model to Enterprise Territory Management, with minor use of Sharing Rules. Prior to the redesign, PA used Salesforce’s Role Hierarchy and more extensive Sharing Rules.
In the following table, we’ve contrasted these approaches at a high level:
| Role Hierarchy | Territory Management | Sharing Rules | |
| How many assignments are allowed? | Users can be assigned to only one role. | Users can be assigned to multiple territories. | Not applicable. |
| Who can access records? | Records can be accessed by the record owner and anyone above them in the Role Hierarchy. However, records are not accessible to other users at the same level in the Role Hierarchy. | Records are accessible to the record owner, any users assigned to the territory above them, and all users assigned to the same territory. | Records are shared based on sharing rules. Only 50 criteria-based sharing rules can be created per object. Note: as of January 2023 this limit can be increased to a maximum of 200. Too many sharing rules can slow down inserts and updates. |
| How are objects shared? | The Role Hierarchy shares records for all objects. | The Territory Hierarchy only shares out Account and child records. Manually sharing or automation is needed to share out other records. | Sharing rules are recalculated whenever record ownership, role/group assignments and sharing rules are changed. This can take a significant amount of time and cause record locking and performance issues. |
Going into more detail, here were the challenges with their previous approach:
Role Hierarchy Pain Points
– Resident service coordinators (RSCs) needed to cover for other sites within other regions.
However, RSCs could not be assigned to multiple roles.
– Site managers (SMs) were able to see records owned by RSCs below them, which were extraneous to them. When an RSC was assigned to cover for a site within another region, the SM was able to see records within the other region.
Sharing Rule Pain Points
– Since only 50 criteria-based sharing rules could be created per object, records had to be shared out by region instead of by site (they have more than 50 locations). This caused users to see a lot of records they did not need/want access to, cluttering their view. Also, this level of access to unnecessary records caused the Program Management Module’s Bulk Service Delivery tool to have significant performance issues.
Solution: Record Visibility with Enterprise Territory Management
The Enterprise Territory Management implementation has allowed resident service coordinators to be assigned to sites outside of their region and see records for all sites they are covering for. Also, site managers no longer have access to unneeded records and performance of the system is more efficient.
Here are the details on how we set it up:
Use Territory Assignment Rules along with Sharing Rules
Salesforce’s Territory Assignment Rules enable an admin to create rules for automatically assigning Accounts and Contacts to Territories. For Project Access, we based the rule on the building the Contact lives in. Also, with territories in place, newly created records for other objects can be shared out to a territory through manual sharing, automation, or sharing rules.
PA uses PMM’s Program Engagements and Program Cohorts to track residents enrolled in specific programs. When a new resident is created, they’re automatically enrolled in various programs based on their age group. Since a resident can be enrolled in multiple programs, we set up automation to share these records with the correct territory. This prevents users from having to access each record and manually share them out.
PA uses PMM’s Service Schedules, Sessions and Deliveries to track residents that attended a class or workshop. For example, a resident may attend an after-school program that occurs three times a week. For each of the objects, we set up criteria-based sharing rules to share records with RSCs by region. Then we created list views for each property and shared the list view to the corresponding territory. This restricted RSCs’ visibility to records for properties they are not assigned to. This setup allowed us to use Salesforce’s out-of-the-box sharing rules and territory sharing of list views, instead of needing to configure complex Flows to share these records.
This mix of security features allows RSCs to only see records for Territories they are assigned to, removing clutter and increasing security.
Automate Record Ownership
Another important piece of visibility was record ownership. PA needed to ensure that RSCs had the access they needed to create records while covering for another location, but restrict access after they left. Standard Salesforce does not meet this need because record visibility is based on ownership. This meant that when an RSC created records for a site they were covering for, the records remained visible to them once they left that location because they were the owner.
PA also needed to ensure these records remained visible to other RSCs in the territory after the covering RSC was no longer at that location. When an RSC was no longer covering a site, they were removed from that territory. However, this also (non-optimally) removed other RSCs’ visibility on the records the covering RSC had created while at that location.
To prevent these issues from happening, we created an automation using Flow that updates the owner of records to a ‘General User’ account. When a record is first created, the owner is set to the user that created the record. Then Salesforce shares this record with other users in the same territory.
Next, our automation runs and updates the record owner to the General User account. Since the record was originally shared to the territory and the General User does not transfer territories, the record visibility will not change when a covering user leaves the location. Now records created by a covering RSC can remain visible to that location without remaining visible to the RSC that covered. Under the original security model, PA’s system administrator needed to track and update the ownership of records each time a covering RSC left. That manual maintenance work is now gone!
Don’t Use The Role Hierarchy
The original Role Hierarchy granted site managers access to records owned by resident service coordinators below them. If an RSC was assigned to cover for a site in another region, their regional manager would get access to the resident information at this new site. Since the covering RSC’s regional manager does not oversee this region, they should not have access to this information. To prevent this from happening, we removed the Role Hierarchy and access to records is now shared using Enterprise Territory Assignment.
Removing Unnecessary Visibility = Increased Performance
Prior to the redesign, Sharing Rules opened up record visibility to all users within a region. This meant that users assigned to a site within a specific region were able to see records for all other sites within the same region. This significantly slowed the performance of the Bulk Service Delivery tool.
Since most of PA’s Sharing Rules were removed during the redesign, the performance of the Bulk Service Delivery tool was significantly boosted and clutter was removed as RSCs now see only the records for sites they are assigned to.
Improve the User Experience with the Right Security Model
Salesforce Enterprise Territory Management is a security model to evaluate for nonprofits with a national focus, where staff also have a specific geographic focus. For Project Access, it overcame several challenges and limitations that came with only using Sharing Rules and the Role Hierarchy. The new security model also dramatically reduced the work for the Salesforce administrator.
Users now see only the records they care about and performance of certain features is much improved.
Interested in learning more or discussing a project? Reach out to chat with us.