Distribution List & Shared Mailbox Membership
Build an internal tool that turns 'just add me to the sales DL' email requests into a tracked, owner-approved workflow: request an add/remove on a distribution list, shared mailbox, or Teams/Slack channel, route it to the list owner, get sign-off, hand IT a clean change task, and keep a real membership register - with stricter approval on all-staff and exec broadcast lists.
A login-protected access tool: request to add or remove someone on a distribution list, shared mailbox, or Teams/Slack channel; auto-route it to the list owner (plus an extra approver for sensitive all-staff/exec lists); the owner approves or rejects; approved changes become a clean change task for IT; the membership register updates; and everything exports as CSV - with a hard rule that no membership ever changes without the owner's recorded sign-off.
Before you start
- A free Vercel account
- A free Supabase account
- A free Resend account (and a sender address you can use)
- A catalog of distribution lists / shared mailboxes / channels with their owners and current members (CSV or Google Sheet)
- A staff list (names + emails)
The problem this kills
Someone emails IT: "Can you add me to the Sales distribution list?" IT adds them. Three months later nobody remembers who asked, whether the Sales manager ever okayed it, or why this person is now getting confidential pricing emails. Multiply that by every distribution list, every shared mailbox, and every Teams and Slack channel in the company, and you have access creeping out of control with zero paper trail.
The worst version: somebody gets added to the all-staff broadcast list with a one-line email, and now anyone who can reach them can blast the entire company. There was no owner approval, no second check, and no record that it ever happened. When security or an auditor asks "who's on this list and who approved them," the honest answer is a shrug.
This tool replaces the untracked email-to-IT with a clear request that goes to the list owner for approval, becomes a tidy change task for IT only after sign-off, and updates a real membership register you can actually trust - with extra protection on the lists that can reach everyone.
What you'll build
A small internal web app, just for your team, that:
- Holds a catalog of your distribution lists, shared mailboxes, and Teams/Slack channels - each with its owner and its current members - imported from a CSV or Google Sheet.
- Lets staff request to add or remove a person on any of these, picking from your staff list (no more typo'd email addresses).
- Shows the current membership of the list right on the request, so everyone has context before deciding.
- Routes each request to the list's owner for an approve/reject decision, via Resend email with a link straight into the app.
- Applies stricter approval to sensitive broadcast lists (all-staff, exec): those need an extra approver on top of the owner before anything happens.
- Turns an approved request into a clean change task for IT - exactly who to add or remove, on which list - instead of a vague email.
- Updates the membership register when IT marks the change done, and keeps a full change history.
- Dedupes so the same add/remove can't be requested twice while one is already open (no duplicate "add me to Sales" floating around).
- Exports membership and change tasks as CSV in the exact columns your mail/collaboration admins need.
What's inside the Implementation Plan
The plan is a single markdown file you paste into Claude Code (a free AI coding agent). It walks the agent through building the whole tool, step by step, each step ending with a ready-to-paste prompt.
The most important part: the plan opens by interviewing you about your business. Before it writes a single line, the agent asks what kinds of lists you manage (distribution lists, shared mailboxes, Teams, Slack), how owners are recorded today, which lists count as sensitive/broadcast, the exact fields and naming in your catalog and staff list, your typical and peak request volume, who the extra approver is for all-staff/exec, and your messy edge cases (an owner who left, a list with no owner, contractors, leavers who need removing everywhere). It reads a short tailored spec back to you, you confirm it, and only then does it build - so you get a tool shaped to your actual access process, not a generic template you have to bend to fit.
Inside you'll find:
- The discovery interview and how the agent turns your answers into the data model.
- The full build: database, login, catalog + staff import, the request flow with current-membership context, owner routing, the extra-approver gate for sensitive lists, the IT change-task handoff, the membership register, and the audit trail.
- The hard human approval gate and the stricter rule for broadcast lists.
- Verification steps so you can prove it works, and the CSV-export fallback so it's fully usable even before you connect it to your mail system's API.
The governance it includes (this is the point)
This isn't a toy. The plan builds in the controls an IT and security team actually needs:
- Login so only your team can see or touch anything.
- Row-level security so people only see the lists and requests that belong to your organization.
- A complete audit trail - every request, approval, rejection, extra-approver sign-off, change task, and membership update is logged with who and when.
- A hard human-in-the-loop gate - the AI drafts and routes, but the list owner must approve before anything becomes a change; sensitive broadcast lists require a second approver too. Nothing is ever auto-applied.
- Stricter approval for broadcast lists - all-staff and exec lists physically cannot be changed on a single owner's nod; the extra sign-off is enforced in code.
- Duplicate guards so the same add/remove on the same list for the same person can't be opened twice while one is already in flight.
Who it's for
IT help desk staff, collaboration and messaging admins, and the list and mailbox owners who keep getting "just add me" emails - anyone who wants membership changes to be requested, approved by the right owner, and recorded, without buying a heavyweight identity-governance platform or hiring a developer. You don't need to write code. You need your list catalog, your staff list, and an afternoon.
You've got this - paste the first prompt and let the agent interview you.