Home / admin / chatter-group-governance

chatter-group-governance

Use when admins are governing the Chatter group lifecycle — creation policy, public/private/unlisted visibility decisions, group ownership transfer when owners leave, archived vs inactive vs deleted state changes, auto-archive behavior, naming conventions, group templates (Information Templates), and orphan-group cleanup after user terminations.

• v1.1.0
• Salesforce Spring '25+
• Updated 2026-09-05
• Operational Excellence
• Security

• chatter-group-governance
• chatter
• collaboration-group
• group-lifecycle
• group-archival
• ownership-transfer

Open the skill folder on GitHub

Chatter Group Governance

Activate this skill when an admin needs to design or repair Chatter group lifecycle controls — naming, visibility, ownership, archival, and cleanup. The skill is about governance of the group population, not about feed noise inside a single group (use admin/chatter-notification-tuning for that).

Before Starting

Gather this context before proposing changes:

• How many groups exist and how many are dormant. Run a quick SELECT COUNT(Id) FROM CollaborationGroup and a follow-up grouped by IsArchived. Most orgs that ask for "governance" have 5–20× more groups than active people, with the bulk dormant for 12+ months.
• Who can create groups today. Group creation is a user permission, not a Chatter Settings checkbox: "Any user with the Create and Own New Chatter Groups permission can create public, private, and unlisted groups, including in any Experience Cloud sites they belong to" (Object Reference, CollaborationGroup Special Access Rules, object_reference.txt L67098–67099). Retrieve the profiles and permission sets and read who actually holds it — broad grants are the single biggest driver of sprawl. Unlisted groups are separately gated by the org setting unlistedGroupsEnabled in Chatter.settings (api_meta.txt L112602–112608).
• What ownership currently looks like. Run SELECT OwnerId, COUNT(Id) FROM CollaborationGroup WHERE IsArchived = false GROUP BY OwnerId ORDER BY COUNT(Id) DESC. Concentrations of ownership on inactive users (User.IsActive = false) are the primary cleanup target. The OwnerId of a group remains pointed at the deactivated user — Salesforce does not auto-reassign on user deactivation.
• Archiving levers, in order. Three of them, at different scopes. Org-wide: allowChatterGroupArchiving in Chatter.settings covers "whether manual and automatic group archiving are allowed on all Chatter groups" (api_meta.txt L112476–112480) — a false here removes the archive option entirely, not just the sweep. Per group, automatic: CollaborationGroup.IsAutoArchiveDisabled exempts one group from the sweep (object_reference.txt L67282–67290). Per group, manual: IsArchived (L67274–67281). Inactivity is measured against LastFeedModifiedDate — "the date of the last post or comment on the group" (L67298–67314) — so a description edit or a member add does not reset the clock.
• Are end users creating private groups for sensitive content? Private and Unlisted groups bypass the standard sharing model for posts inside the group — a Private group is a parallel data island. Compliance teams care.

Questions to Ask Before Configuring

Ask these before touching Setup or writing a cleanup script. Each one maps to a gotcha that turns a tidy-looking cleanup into an irreversible one.

What a proper configuration adds over just archiving the dead groups: the org keeps a discoverable, auditable group population — every active group has a reachable owner, every exemption from the archive sweep is a deliberate per-group flag rather than an org-wide switch, unlisted groups are either governed by a named permission holder or turned off, and the settings baseline lives in source control so the next org inherits the same policy instead of rediscovering it.

Core Concepts

Concept 1 — Three group types, three sharing models

CollaborationGroup.CollaborationType is a picklist with three values that drive visibility very differently:

Two consequences admins miss:

• A Public group is the only type where post content is visible to non-members. If the goal is "broadcast announcement," Public is correct. If the goal is "team workspace with sensitive material," it must be Private or Unlisted.
• Unlisted groups are invisible to admin seniority as well as to end users, and this is the most-often-wrong belief in the topic. The guide states it twice: a View All Data holder "can't view unlisted group information, unless they have the Modify Unlisted Groups permission as well," and a Modify All Data holder "can't view or modify unlisted group information, unless they have the Manage Unlisted Groups permission as well" (L67109–67115). A SOQL query run by an ordinary system admin therefore returns an incomplete group list and says nothing about what it omitted. Either provision Manage Unlisted Groups to named compliance holders or set unlistedGroupsEnabled to false — references/metadata-examples.md sections 1 and 2 carry both.

Concept 2 — Archived ≠ Inactive ≠ Deleted

Three distinct lifecycle states. Confusing them is the most common admin error:

• Active — IsArchived = false. Group accepts new posts, members receive notifications, group counts against any per-org group limits in shipped product features.
• Archived — IsArchived = true. Set by the org's automatic sweep against LastFeedModifiedDate, or manually by the owner or a Modify All Data holder. Archived groups:
  • Stay in CollaborationGroup — not deleted.
  • Past posts and members are preserved and queryable.
  • No new posts accepted via UI; the group becomes read-only.
  • Members continue to be members; EntitySubscription records persist.
  • The group can be unarchived (manually only) and resume activity.
• Deleted — record-level delete on CollaborationGroup, and the cascade reaches outside the group: "Deleting a group permanently deletes all posts and comments to the group. It also deletes all files and links posted to the group and removes the files from other locations where they were shared" (L67402–67404). Compliance impact: the audit trail of group conversations is gone, and so is any file that also lived in three other places.

There is no "Inactive" state in metadata — the term is colloquial for "Archived but not yet Deleted." Decide explicitly: archive (preserve audit trail, hide from active lists) or delete (purge permanently).

Concept 3 — Group ownership and the deactivated-owner problem

CollaborationGroup.OwnerId is a hard reference to a User record. Two non-obvious behaviors:

1. Deactivating the owner does NOT reassign the group. The user is set IsActive = false. The group's OwnerId still points at them. The group continues to function — members can post, the group can be modified by other group managers — but the owner-only operations (deleting the group, transferring it, changing its type) are now stuck unless a system admin intervenes.
2. Only the current owner or a Modify All Data holder can transfer ownership — "Only the current group owner or people with the Modify All Data permission can update the OwnerId" (L67378–67379). Not "an admin" loosely: that specific permission. The member-side note says the same thing from the other direction — "To change the group owner, use the OwnerId field on the CollaborationGroup object" (L67477–67478) — so promoting someone to group manager is explicitly not a transfer.

The governance pattern: every group should have a backup manager (a CollaborationGroupMember with CollaborationRole = 'Admin' — "Managers can post and comment, change member roles, edit group settings, add and remove members, delete posts and comments, and edit the group information field", L67473–67476). The backup manager covers moderation but cannot transfer ownership; a Modify All Data holder must do that. So the offboarding workflow is:

• Detect groups owned by users being deactivated (run before the deactivation, ideally).
• Reassign owner to the named backup manager (or to a generic "Chatter Stewards" service account if no backup exists).
• Then deactivate the user.

Doing it in the other order leaves orphaned-owner groups that require manual cleanup later.

Concept 4 — Group templates (Information Templates) and naming conventions

Salesforce ships Group Information Templates — admin-configured Markdown-style templates that prefill the group's "Information" tab on creation. Two practical uses:

• Encode naming convention in the template. The template can include explicit guidance ("Name format: Team-<Department>-<Purpose>") and required sections (Charter, Members, Cadence). Users who follow the template produce navigable groups; users who skip the template produce orphans.
• Encode lifecycle policy in the template. Include "Owner backup," "Auto-archive after N days," "Delete trigger" sections. This makes the policy visible at creation time, not buried in admin docs.

Templates do not enforce anything — a determined user can ignore them. But combined with restricting group creation to a permission set (so only "trained" users can create groups at all), they cut sprawl materially.

A common structural naming convention for orgs of any size:

<Type>-<Scope>-<Purpose>

Examples:
  Project-AcmeMigration-CoreTeam        ← a project workstream
  Team-Sales-EnterpriseAEs              ← a standing team
  Topic-Salesforce-ReleaseTrack          ← an interest / topic group
  Announce-AllHands                      ← broadcast group
  Customer-AcmeCorp-AccountTeam         ← a customer-specific group

Prefixes like Project-, Team-, Topic-, Announce-, Customer- make bulk operations (archive all Project-* groups closed last quarter) trivial via SOQL WHERE Name LIKE 'Project-%'.

Recommended Workflow

1. Retrieve the metadata baseline and lint it. sf project retrieve start --metadata Settings:Chatter,PermissionSet,Profile, then run the bundled checker:

   python3 scripts/check_chatter_group_governance.py --manifest-dir force-app/main/default

   Two findings stop everything else: CGG-UNLISTED-UNGOV (unlisted groups are on and nobody holds Manage Unlisted Groups, so your inventory in step 2 will be incomplete) and CGG-ARCHIVE-OFF (archiving is disabled org-wide, so the archive branch of step 4 does not exist yet). references/metadata-examples.md sections 1–2 carry the deployable Chatter.settings and PermissionSet shapes for whatever you have to change.

2. Export the group population and lint that too. Groups are data, not metadata — the export query

   is in references/metadata-examples.md section 3. Run it as a user who holds Manage Unlisted Groups if step 1 says one exists, then:

   python3 scripts/check_chatter_group_governance.py \
       --manifest-dir force-app/main/default \
       --group-inventory groups.csv \
       --name-prefixes Project- Team- Topic- Announce- Customer- \
       --inactive-days 365

   CGG-INV-ORPHAN is the ownership-transfer queue, CGG-INV-STALE the archive queue, CGG-INV-EMPTY the delete candidates, CGG-INV-NAMING the convention debt. Record the counts — they are the baseline you re-measure against in step 7.

3. Decide creation policy, and write it as metadata. Move Create and Own New Chatter Groups off

   profiles and onto a named Chatter_Group_Creator permission set; add Unlisted_Group_Auditor if the org keeps unlisted groups. Both shapes are in references/metadata-examples.md section 2 — read the UNVERIFIED note there about the permission API names before you deploy them.

4. Reassign every orphaned owner, before you archive anything. Use the manager-first script in

   references/metadata-examples.md section 4: it prefers an active group manager and falls back to a steward service account, in three queries and one partial-success DML. Archiving a group whose owner is already gone just hides the problem — gotchas 2 and 3.

5. Split stale from empty, then archive or delete. Archive (IsArchived = true) anything with

   substantive history; delete only groups the checker flagged CGG-INV-EMPTY and whose direct CollaborationGroupMember count you confirmed — MemberCount is a nillable rollup, gotcha 9. Before any delete, check the group's files: the delete cascade removes them from every other location they were shared into, gotcha 7. Standing groups that should never auto-archive get IsAutoArchiveDisabled = true instead (section 5 of the metadata examples), not an org-wide setting change.

6. Wire the offboarding hook and sequence it. Ownership transfer runs before User.IsActive flips.

   Read references/llm-anti-patterns.md anti-pattern 2 first — the obvious record-triggered Flow is the wrong shape here. And if this is a deactivation wave, read gotcha 11: deactivating several users at once hard-deletes the follow relationships between them, with no restore on reactivation.

7. Re-measure quarterly and diff the counts. Re-run both checker invocations from steps 1–2.

   CGG-INV-ORPHAN should trend to zero, CGG-INV-NAMING should fall as the permission set narrows who creates groups, and a rising archived-to-active ratio is health, not decay. Commit the Chatter.settings and permission-set files so the policy travels with the org.

Reference Files

Related Skills

• admin/chatter-notification-tuning — feed noise, digest frequency, and notification volume tuning inside groups (this skill governs the group population; that skill governs what's noisy inside a group)
• apex/apex-connect-api-chatter — programmatic group creation / membership / posting via Connect API
• admin/user-management — broader user-deactivation workflow that this skill plugs into for the ownership-transfer step

Package files

• references/examples.md
• references/gotchas.md
• references/llm-anti-patterns.md
• references/metadata-examples.md
• references/well-architected.md
• templates/chatter-group-governance-template.md
• scripts/check_chatter_group_governance.py