The problem

Distribution-list and group-membership requests are high-volume but low-risk: users want to be added to a project mailing list, an announcement channel, or a shared calendar group. The approval pattern is straightforward, but manual handling consumes IT time on what is fundamentally a self-service-eligible operation.

What AscendCore does

A user requests addition or removal from an M365 distribution list, mail-enabled security group, or Microsoft 365 group via Microsoft Teams or Slack. AscendCore resolves the group by display name, proposes the membership change to the IT admin channel with the group type clearly labeled (so approvers can apply the appropriate policy), executes via Microsoft Graph on approval, and writes a tamper-evident audit row.

Commands

/group-add <user-email> "<distribution list name>"
/group-remove <user-email> "<distribution list name>"

The /group-add and /group-remove commands serve all three group types — distribution lists, mail-enabled security groups, and Microsoft 365 groups — because Microsoft Graph treats them identically at the membership endpoint. The approval card surfaces the resolved group type ("Distribution list", "Mail-enabled security group", "Microsoft 365 group", "Security group") so IT admins know exactly what's being authorized.

Workflow

Detect — slash command (Slack) or message (Teams) with the user email and group name
Resolve — match the requested name to a real Entra group ID; if multiple groups match, surface disambiguation suggestions
Classify — read groupTypes / mailEnabled / securityEnabled from Microsoft Graph and label the type for the approver
Propose — admin approval card with member, group, group type, group ID, description
Approve — IT admin clicks Approve in the configured admin channel
Execute — POST /groups/{id}/members/$ref (add) or DELETE /groups/{id}/members/{userId}/$ref (remove)
Notify — requester DM'd by the bot; approval card updated in admin channel
Audit — group_membership.added or group_membership.removed row appended to the SHA-256 hash chain

Integrations

Microsoft 365 — Distribution group + Microsoft 365 group membership APIs (via Graph /groups/{id}/members/$ref)
Microsoft Entra ID — Same Graph endpoint handles security groups and mail-enabled security groups
Slack + Microsoft Teams — Request trigger and confirmation surface, with full Adaptive Card and Block Kit parity

Status

Live in production — shares the same wired flow as the security-group membership runbook (RB-013). Same Microsoft Graph endpoint, same audit chain, same approval card UX, with the group type clearly disambiguated for the approver. Verified end-to-end with cryptographic chain integrity.

Versioned, deterministic, auditable

Every runbook is defined as a versioned YAML manifest with explicit triggers, steps, and approval policies. The runbook itself is the audit-ready record of what AscendCore can and will do — chat is just the interface that triggers it.

name: distribution-list-add trigger: channels: [slack, teams] intents: [group_add, group_remove] # Microsoft Graph treats security groups, M365 groups, and distribution # lists identically at /groups/{id}/members/$ref. The same /group-add # and /group-remove commands serve all three; the approval card labels # the group type so the approver knows what they're authorizing. steps: - resolve_group_by_name - admin_approval - update_m365_group approval: required: true approvers: [it-admins] # Manager-routed approval (DM the requester's manager directly) is on # the Enterprise-tier configuration roadmap; today all approvals route # to the configured admin channel for consistent audit-trail behavior.

Email Distribution List Add