Hi everyone,
We're having issues in our org with reorgs. They seem to happen constantly and we also get special requests to have managers see the opportunities of certain individuals who aren't their direct report in our org chart, so using something like a copy from AD is out of the question.
My question is: What's the fastest/best way to handle these reorgs? They usually take us hours at a time and Salesforce is one of many priorities since we wear multiple hats, so it's not something we can spend all our time on. If there's an easy way to handle these that'd be great.
#Salesforce Admin #Salesforce Developer #Salesforce
Hi @Collin Thao
,
Recommended Approach:1. Redesign roles around data visibility, not reporting lines.
Roles should be few and stable (e.g. by region, segment, or function), not one per manager or team. When a rep changes managers but stays in the same segment, nothing in Salesforce changes. A role hierarchy that mirrors the org chart is the usual cause of constant rework.
2. Handle the "manager sees non-direct-report opps" exceptions outside the hierarchy.
This is the part that makes copying from AD unworkable, and it's best handled with sharing, not roles:
- Owner-based sharing rules + public groups: "Opportunities owned by members of Group A are shared with Group B (Read Only)". Exceptions become group membership edits (about 30 seconds each).
- Opportunity Teams or manual sharing for one-off, deal-level cases.
- Optionally, delegate public group management to an ops lead through Delegated Administration, so it's not all on you.
3. Make the reorg itself a spreadsheet job, not a click-through.
Keep a template CSV (UserId, RoleId, ManagerId, public group membership). Export the current state, edit, and upsert with Data Loader (or Data Import Wizard for groups). Hours become minutes. A bulk reorg also triggers sharing recalculation, so use
Defer Sharing Calculations(Setup) while you make the changes, then recalculate once at the end.
4. If reorgs are really about geography or segment, consider Enterprise Territory Management.Moving accounts between territories is rule-driven rather than person-by-person. It's a bigger project, so only worth it if that's what's actually changing.
5. Remember Manager and Role are separate fields.User.ManagerId drives approvals and similar features. Role drives record visibility and forecast rollups. Update them independently so you're not forced to restructure roles for a manager change.
Trade-offs to know about
- Sharing rules can't grant more access than the OWD allows to begin with. They only open it up, so this works if Opportunity OWD is Private or Public Read Only.
- Forecast rollups follow the role hierarchy. If non-direct-report managers need those rollups too, sharing alone won't give you that. You'd need a Forecast hierarchy or role adjustment.
- Changing the role structure itself is a visibility change org-wide, so test in a sandbox first and get sign-off before touching production.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
