Flexible Teams Share brings the native Salesforce team model to any standard or custom object. If you can create a team on an Account, you can create a team on a Project, an Engagement, or any record that needs collaborative access. Team owners manage membership directly, each role maps to an access level, and when someone joins or leaves, their access updates automatically.
How Does Flexible Teams Share Work?
The model mirrors what you already know from Account Teams and Opportunity Teams. You define team roles once (Technical Lead, Business Analyst, Executive Sponsor). Each role maps to an access level: read, edit, or full control. When you assign a record to a team, every team member receives the access defined by their role.
The difference: it works on any object you choose, not just Account, Opportunity, and Case.
Business User Self-Service
The orgs that benefit most from this approach are the ones drowning in “please add me to this project” tickets. When team owners can manage their own membership, two things happen: access changes faster (minutes instead of days), and admin workload drops.
I’ve seen this pattern across implementations: organizations that give business users control over team membership spend less time on access management and more time on actual work. The access model becomes transparent because everyone can see who’s on the team and why.
Security Model Preserved
Team owners can only grant access up to their own level. If a team owner has Edit access, they can’t add someone with Full Control. You’re moving administration closer to the people who understand the business context, not bypassing security.
What It Looks Like in Practice
A Project record has a team. The project manager adds team members and assigns roles. Each role has predefined access levels. When someone joins the team, they immediately see the record. When they leave, access is revoked automatically.
No tickets to IT. No waiting for deployment windows. No code changes when the team structure evolves.
Why Native Teams Don’t Work on Custom Objects
Salesforce built Account Teams, Opportunity Teams, and Case Teams for specific use cases. The architecture is tightly coupled to those three objects. There’s no configuration option, no hidden setting, no workaround that makes native teams work on a custom object like Project__c or Engagement__c.
This becomes a problem when your business processes don’t fit neatly into Accounts, Opportunities, and Cases. Professional services firms track Projects. Consulting companies manage Engagements. Healthcare organizations coordinate Care Plans. Manufacturing companies handle Work Orders. None of these get native team support.
The pattern I see repeatedly: organizations build custom objects to match their actual business processes, then discover they can’t use the team model that works so well on standard objects.
What Are the Typical Workarounds (And Their Problems)?
When native teams aren’t an option, organizations usually try one of three approaches. Each solves the immediate problem but creates new ones.
Apex Managed Sharing
Apex managed sharing gives you programmatic control over sharing records. You write triggers or batch jobs that create Share records when certain conditions are met.
The problem: someone has to write that code, test it, and maintain it. When business requirements change (and they always do), a developer has to modify the logic. The code becomes part of your technical debt. In orgs I’ve worked with, Apex sharing logic often becomes the thing nobody wants to touch because the original developer left and the documentation is sparse.
Manual Sharing
Manual sharing is the simplest approach: record owners click the Sharing button and add users one by one. No code, no admin involvement for each share.
The problem: it doesn’t scale. When you have hundreds of records and team membership changes frequently, manual sharing becomes a full-time job. People forget to remove access when someone leaves a project. There’s no audit trail of why someone was added.
Criteria-Based Sharing Rules
Sharing rules let admins define criteria that automatically grant access. If a record meets certain conditions, specified users or groups get access.
The problem: sharing rules are org-wide and static. You can’t say “share this specific Project with this specific team.” You have to create rules that match patterns, which gets complicated fast. Orgs hit the sharing rule limit (50 criteria-based rules per object) sooner than expected. And every rule change requires an admin, which creates bottlenecks.
The Common Thread
All three workarounds shift the burden somewhere: to developers (Apex), to record owners (manual), or to admins (sharing rules). None of them give business users the self-service team management they get with native Account Teams.
When Does This Approach Make Sense?
Team-based sharing on custom objects isn’t the right fit for every scenario. It works well when:
You have defined team structures. If people naturally work in teams on specific records (projects, engagements, cases, accounts), extending the team model makes sense. If access is purely role-based or org-wide, standard sharing rules may be sufficient.
Team membership changes frequently. Static sharing rules work fine when access patterns don’t change. But when people join and leave projects regularly, self-service team management saves significant overhead.
Business users understand who should have access. Project managers know who’s on their project. Engagement leads know their team composition. Pushing access decisions to the people with context produces better results than centralized admin guessing.
You’re approaching sharing rule limits. Each criteria-based sharing rule consumes a limited resource. Team-based sharing sidesteps this by handling access at the record level rather than the org level.
Key Takeaways
- Flexible Teams Share extends the native team model to any object: same pattern you know from Account Teams, works on custom objects
- Business users manage their own teams: no admin tickets, no deployment cycles, access changes in minutes
- No code to maintain: unlike Apex sharing, there’s nothing to write, test, or debug when requirements change
- Native workarounds have tradeoffs: Apex needs maintenance, manual sharing doesn’t scale, sharing rules hit limits
- Best fit: defined team structures, frequent membership changes, business users who understand access requirements
Related Articles
Written by
Artur Kolasa
Senior Architect | Salesforce CTA
Salesforce Certified Technical Architect (CTA). Deep background in enterprise Salesforce architecture. Every solution we build is designed or reviewed by a CTA.