Salesforce Team Sharing is a permission model that extends record access beyond ownership and role hierarchy. It enables cross-functional collaboration by allowing record owners or administrators to share specific records with teams, public groups, or individual users without modifying org-wide defaults or restructuring your role hierarchy.
How Does Team Sharing Actually Work?
Team sharing operates through sharing rules that grant access to specific records based on team membership rather than organizational hierarchy. When a user is added to a team, they automatically gain access to records shared with that team.
The key mechanisms include:
- Manual sharing: Record owners share individual records
- Sharing rules: Administrators create criteria-based sharing
- Apex managed sharing: Programmatic sharing for complex scenarios
- Teams: Account Teams, Opportunity Teams, Case Teams
Implementation Note
Team sharing rules are evaluated at runtime. Changes to team membership take effect immediately without requiring a full sharing recalculation.
Sharing recalculation time is the metric that catches most orgs off guard. I’ve seen implementations where adding one more criteria-based rule pushed recalc from minutes to hours. The orgs that manage this well treat sharing rules like technical debt: they review them periodically, remove unused ones, and consolidate overlapping criteria before performance becomes a problem.
What Problems Does Team Sharing Solve?
Traditional role hierarchy works vertically: managers see what their direct reports see. But modern organizations don’t operate purely vertically.
Common challenges team sharing addresses:
- Cross-functional deal teams: Sales, legal, and finance need to collaborate on the same opportunity without being in the same reporting line
- Regional specialists: A product expert needs visibility into accounts across multiple territories
- Project-based access: Temporary access for initiative-specific collaboration
- Partner collaboration: External partners need limited access to specific records
The scenario I encounter most often: teams need to collaborate on custom objects (Projects, Engagements, client-specific records) but standard sharing doesn’t fit. Before, this meant either complex Apex sharing code that nobody wants to maintain, or admin-managed sharing records that fall out of sync within weeks. The orgs that move to team-based sharing on custom objects usually report two things: less admin overhead and fewer “I can’t see this record” support tickets.
When Should You Choose Team vs. Role-Based Sharing?
The decision depends on your access pattern:
| Scenario | Recommended Approach |
|---|---|
| Manager needs visibility to team’s records | Role Hierarchy |
| Cross-department collaboration on specific records | Team Sharing |
| Executive dashboards across org | Role Hierarchy |
| Project-based temporary access | Team Sharing |
| Compliance-based access restrictions | Sharing Rules + Teams |
Performance Consideration
Excessive sharing rules can impact query performance at scale. Test with production-like data volumes before deploying.
How Do You Implement Team Sharing in Your Org?
Step 1: Define Your Sharing Model
Start by mapping your collaboration patterns:
- Who needs to share records with whom?
- Is the access pattern temporary or permanent?
- What level of access is required (Read, Edit)?
Step 2: Configure Teams and Groups
For standard Salesforce team sharing:
Setup → Users → Public Groups → New Group
Setup → Accounts → Account Teams → EnableFor flexible team structures, consider Flexible Teams Share which extends native team functionality to any object.
Step 3: Create Sharing Rules
Navigate to Setup → Sharing Settings and create criteria-based or owner-based sharing rules that reference your teams.
Step 4: Test and Validate
Use the Sharing Hierarchy button on records to verify access grants are working as expected.
Every sharing model I’ve implemented gets the same test: I create users for each role and profile combination, then systematically check what they can and can’t access. Can they see the record? Edit it? See related records? It’s tedious, but skipping this step is how sharing bugs make it to production. The bugs are always the same: someone assumed access would cascade, or a permission set grants more than expected. Testing catches these before users do.
What Are Common Team Sharing Pitfalls?
1. Over-Sharing
Opening access too broadly defeats the purpose of your security model. Start restrictive and expand based on demonstrated need.
2. Orphaned Sharing Records
When users leave teams, their manual sharing records may persist. Implement cleanup routines.
3. Performance at Scale
Large numbers of sharing rules require careful indexing and query optimization. Monitor SOQL query performance.
4. Inconsistent Patterns
Different teams implementing sharing differently creates confusion. Document and standardize your approach.
Architecture Decision Record
Document your sharing model decisions in ADRs. Future administrators will thank you.
Key Takeaways
- Team sharing extends, not replaces, role hierarchy: use it for horizontal collaboration patterns
- Start with clear requirements before implementing. Map who needs access to what
- Test at scale with production-like data volumes before deployment
- Document your decisions in architectural decision records for maintainability
- Consider managed packages like Flexible Teams Share for complex team structures
Related Articles
Written by
Michał Bajdek
Application & System Architect
Salesforce System & Application Architect with 12+ years experience. 50+ enterprise projects across Accenture, PwC, IBM. Clean architecture that teams can extend.