What happens when you try to delete a public group?

Short answer

When you try to delete a public group in Salesforce, the system will prevent deletion if the group is referenced by active configuration (for example, sharing rules, folder shares, queues, assignment rules, Apex metadata, or other dependencies). If no references exist, the group is deleted and all memberships are removed — any access that depended solely on that group is lost. Always check for dependencies first and remove or replace references before deleting.

Why this matters (SEO keywords: delete public group Salesforce, public group deletion, Salesforce sharing rules)

Public groups are commonly used for record sharing, report/dashboard folder access, queues, and automation. Deleting a public group without checking where it’s used can silently break access, assignment, or automation flows. This article explains what happens, how to find dependencies, and safe steps to delete a public group.

What Salesforce does when you attempt deletion

There are two possible outcomes:

• Blocked deletion: Salesforce will block the delete action if the group is actively referenced by certain metadata (notably sharing rules and some controls). You’ll receive an error telling you where the group is used or that the delete failed due to references.
• Successful deletion: If the group has no blocking references, Salesforce deletes the Group record and removes any GroupMember entries. Any permissions, folder access, or sharing that relied only on that group will be removed, which can lead to loss of access for users who were members via the group.

Common places a public group can be referenced

Before deleting a group, check these locations:

• Sharing rules (Account, Opportunity, Custom Object shares): groups often appear as the recipient in sharing rules.
• Queues (queue membership can include public groups).
• Report and Dashboard folder sharing (folder access can be granted to groups).
• Manual sharing and existing share rows (Share objects use UserOrGroupId).
• Assignment rules, escalation rules, or approval processes referencing groups.
• Apex metadata, validation rules, flows, Process Builder, or custom code that reference the group by Id or name.
• Email alerts, list views, and folder subscriptions that target a group.

How to find references (use Developer Console or Workbench)

Use SOQL to spot where a group is used. Replace <GROUP_ID> with your Group Id.

// Members of the group
SELECT Id, GroupId, UserOrGroupId FROM GroupMember WHERE GroupId = ''

// Queues that reference the group as a member
SELECT Id, Name FROM QueueSobject WHERE QueueId IN (SELECT QueueId FROM Group WHERE Id = '')

To find share rows that reference the group (example for Accounts):

// Account shares referencing the group
SELECT Id, AccountId, UserOrGroupId, RowCause FROM AccountShare WHERE UserOrGroupId = ''

Check other share tables similarly (OpportunityShare, CustomObject__Share) using UserOrGroupId column.

If you don’t know the Group Id, find it by name:

SELECT Id, Name, Type FROM Group WHERE Name = 'My Public Group'

Safe deletion process

1. Identify the Group Id and list GroupMember entries.
2. Search sharing rules, folder shares, queues, assignment/approval rules, flows, and Apex for references. Remove or update references to a replacement group or user where required.
3. Manually remove the group from any queues or folder-sharing entries.
4. Re-run SOQL checks to confirm no blocking references remain.
5. Delete the public group from Setup → Users → Public Groups.
6. Monitor logs and access reports to ensure no unexpected access loss.

Rollback / recovery options

There is no automatic “undo” for deleting a public group. To recover, you must recreate the group (same name and members) and re-create the metadata references (sharing rules, folder shares). Use the Setup Audit Trail and deployment tools (Change Sets, Metadata API) to rebuild what was removed.

Best practices

• Use naming conventions and documentation for groups so dependencies are easier to track.
• Prefer Permission Sets and Roles for long-term access patterns and use groups for flexible, short-term sharing.
• Before deleting any group, run targeted SOQL checks and export results to a CSV.
• Use sandbox testing to validate the deletion impact before making changes in production.

If you want, I can generate the exact SOQL queries for all relevant share tables in your org (Account, Opportunity, each CustomObject__Share) — provide the Group Name or Id and I’ll prepare them.