So you want to use hierarchical security to give your sales managers access to their team’s account records. One thing that you should be aware of is how hierarchical security works when users are disabled.
If a user becomes disabled, records that he or she owns are not available for hierarchical security. This is a performance related limitation but is not currently documented in the official documentation.
- If a user who owns account records leaves the company, your offboarding process should include reassigning his records to another user (or to the sales manager).
- If #1 is not practical, such as high turnover scenarios or where there is no current replacement for the territory, consider creating a team for each sales manager called something like “west territory-open.” Make the sales manager a member of the team, then assign the disabled user’s records to the open team. That way the manager can see and manage those accounts, but they will be open so that when a replacement is hired, they can be reassigned to the new user.
- If none of these options work, consider an alternative to hierarchical security. One common approach that we frequently did prior to the introduction of hierarchical security was to create an access team on Account that grants the desired managerial permission, then have a nightly batch job (using KingswaySoft, Scribe, or some other ETL tool) that builds the access team membership with the sales manager for each account. This approach avoids the problem of sharing, as well as the limitations in hierarchical security.