> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Distribution List Management

> Add or remove distribution-list members with owner approval and a documented reason. Use when a ticket asks to add someone to, remove someone from, or clean up a distribution list or email group.

<Info>
  **Category:** Onboarding & Access · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/onboarding-and-access/distribution-list-management/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** "Add \<user> to the sales distribution list" / "remove \<user> from announcements — they moved teams" / "who approves changes to the leadership DL?" — or a DL change inside a broader onboarding/offboarding ticket.

**Run it:** on one ticket — approval-gated, so a human confirms membership changes.

## Prompt

```
Handle this DL membership change so every add and remove has an approver and a
rationale on record.

1. Identify the exact list (clients often have similarly named DLs — confirm the
   address, not just the display name), the member to add/remove (look up the contact),
   and the stated reason.

2. Find the list owner or the client's documented approval rule (check the knowledge
   base and their IT documentation in IT Glue). Get owner approval before changing
   membership (send an approval request, or use the client's channel). Exceptions:
   removals that are part of an authorized offboarding, and adds covered by a documented
   role profile (new sales hire → sales DL) — cite the covering policy instead.

3. Sanity-check the change: adding an external address to an internal list, or anyone
   to a broad-reach list (all-staff, leadership, client-facing), gets flagged to the
   approver explicitly rather than buried in a routine request.

4. Execute the change. If the list is synced from on-prem AD, make the change on the AD
   side, run an AD Connect delta sync, and verify before reporting done.

5. Post a plain-text note: list address, member added/removed, approver, and the
   documented rationale. Log time and confirm to me.

Guardrails: no membership change without owner approval or a citable standing policy.
External addresses and broad-reach lists always get an explicit approver callout —
never treat those as routine. Confirm the exact list address before changing anything;
a near-name match is not a match. Record the rationale — "user requested" alone is not
a rationale. Bulk cleanups (many removals at once) get a proposed list posted for
approval first — never bulk-remove unattended.
```


## Related topics

- [Distribution vs M365 Groups](/skill-library/m365-administration/distribution-vs-m365-groups.md)
- [Access Request Handling](/skill-library/onboarding-and-access/access-request-handling.md)
- [Access Request Intent Design](/skill-library/automation-and-flows/intent-design-access-request.md)