Salesforce documentation states that to edit/remove Account Team Members, users need Read access on Users, Edit access on Accounts, and to be the Account Owner or above the Account Owner in the role hierarchy.
However, the same documentation also states that users in a Public Group with Edit access to an Account granted through a Sharing Rule can add/remove Team Members.
Article:
Working with Teams on Your Accounts | Salesforce Help
I tested the Public Group approach. The user in my project already has Read access on Users and Edit access on Accounts, and further I created the Public Group receives Read/Write Account record access through a Sharing Rule.
Even after this, they do not get the Edit/Delete row actions and also don't see the Remove All Members option.
Can someone clarify how the “remove” access mentioned for Public Groups is expected to work in Lightning?
Note: I would prefer not to use the other options, such as ownership, Modify All, role hierarchy, or a custom Flow running in system mode, just to provide this access for couple of users.
So, looking for confirmation does removing a team member still require the user to be the Account Owner, above the Account Owner in the role hierarchy, or have broader access such as Modify All? If so, what does the Public Group documentation mean by “add/remove Team Members”?
Hi Sana,
Good catch — this looks like a genuine documentation inconsistency, and your test result matches known real-world behavior: the Lightning UI's Add Team Members / Remove All Members buttons are gated by a hardcoded ownership/role-hierarchy check, not by generic "Edit access to the Account" from any source. Sharing-Rule-granted edit access (via Public Group) satisfies the underlying object permission for API/Apex DML, but doesn't unlock the row-level UI actions in Lightning.
So to directly answer your question: yes, in practice, removing/adding a team member via the standard Lightning UI still requires the user to be the Account Owner, above the Owner in role hierarchy, or have Modify All — Sharing Rule access alone doesn't surface those UI controls, regardless of what the "Public Group" bullet implies.
What that bullet likely refers to: doing it via the API/Apex directly (not the standard related-list buttons) — a user with Sharing-Rule-based Edit access can successfully insert/delete AccountTeamMember records programmatically, even though they won't see the buttons in the UI. Worth testing that specifically (e.g., via Workbench or an anonymous Apex insert as that user) to confirm — if that succeeds, it confirms the doc is describing API-level access, not the Lightning UI experience.
If you need this for a couple of specific users without ownership/Modify All, a small custom LWC/Quick Action calling Apex (with sharing) to add/remove members would work, since the underlying permission is already there via your Sharing Rule — you'd just be bypassing the UI's hardcoded ownership check.
Reference:
https://help.salesforce.com/s/articleView?id=sales.accountteam_add.htm&language=en_US&type=5Worth submitting feedback on that Help article too, since the wording does read as if the UI buttons should work for Sharing-Rule access.