# Technical Reference

# M365 Email Groups, Role Inboxes & Responsibilities

*Operational reference for office staff, IT admin, and future volunteers — mailing lists, shared mailboxes, licensing, SOPs, and governance.*

---

<a id="bkmrk--1"></a>## Quick Overview

SHHA uses two different patterns for email collaboration:

 <table id="bkmrk-patterntechnologyexa"> <thead><tr><th>Pattern</th><th>Technology</th><th>Examples</th></tr></thead> <tbody> <tr> <td>**Committee mailing lists**</td> <td>Microsoft Groups</td> <td>`shha-all@`, `csc@`, `acc@`</td> </tr> <tr> <td>**Role-based addresses**</td> <td>Shared mailboxes</td> <td>`president@`, `cscchair@`, `accchair@`</td> </tr> </tbody> </table>

---

<a id="bkmrk--3"></a>## Design Principles

- **Role continuity over individual ownership** — email addresses stay constant when people rotate in/out.
- **Least cost for volunteers** — external volunteers do not require paid M365 licenses.
- **Operational traceability** — group membership changes trigger Power Automate notifications.
- **Institutional archive** — `itadmin@` is included in all groups as a permanent archive recipient.
 
---

<a id="bkmrk--5"></a>## Microsoft Groups (Mailing Lists)

Each committee has a Microsoft Group that acts as its mailing list.

 <table id="bkmrk-groupaddress-all-mem"> <thead><tr><th>Group</th><th>Address</th></tr></thead> <tbody> <tr><td>All members</td><td>`shha-all@sandiahomeowners.org`</td></tr> <tr><td>CSC</td><td>`csc@sandiahomeowners.org`</td></tr> <tr><td>ACC</td><td>`acc@sandiahomeowners.org`</td></tr> <tr><td>Others</td><td>One group per committee</td></tr> </tbody> </table>

**Behavior:** Sending to the group distributes to all members. Membership is maintained by staff (primary owner: Anna). External participants can be included.

---

<a id="bkmrk--7"></a>## Shared Mailboxes (Role Inboxes)

Chair and executive role addresses are shared mailboxes tied to positions, not people.

 <table id="bkmrk-roleaddress-csc-chai"> <thead><tr><th>Role</th><th>Address</th></tr></thead> <tbody> <tr><td>CSC Chair</td><td>`cscchair@sandiahomeowners.org`</td></tr> <tr><td>ACC Chair</td><td>`accchair@sandiahomeowners.org`</td></tr> <tr><td>President</td><td>`president@sandiahomeowners.org`</td></tr> <tr><td>Vice President</td><td>`vicepresident@sandiahomeowners.org`</td></tr> <tr><td>Secretary</td><td>`secretary@sandiahomeowners.org`</td></tr> <tr><td>Treasurer</td><td>`treasurer@sandiahomeowners.org`</td></tr> </tbody> </table>

### Access model

- People do **not** log in directly as the role mailbox.
- Authorized users open the shared mailbox from their own licensed account.
- Example: `phil.krehbiel@sandiahomeowners.org` can open `accchair@sandiahomeowners.org`.
 
### When leadership changes

1. Remove predecessor access.
2. Grant successor access.
3. Keep the role mailbox address unchanged.
 
---

<a id="bkmrk--9"></a>## Archive Mailbox (`itadmin@`)

- `itadmin@` is a member of **all** groups.
- Purpose: permanent archive and continuity.
- `itadmin@` is **not actively monitored** for normal operations.
 
---

<a id="bkmrk--11"></a>## Power Automate Membership Notifications

A Power Automate flow sends email notifications whenever group membership changes.

- Provides audit visibility.
- Alerts staff to unexpected changes.
- Supports handoffs and troubleshooting.
 
---

<a id="bkmrk--13"></a>## Licensing and External Volunteers

 <table id="bkmrk-user-typelicense-nee"> <thead><tr><th>User type</th><th>License needed?</th><th>Capabilities</th></tr></thead> <tbody> <tr><td>External volunteers</td><td>**No**</td><td>Group email delivery, SharePoint guest access</td></tr> <tr><td>Licensed staff / admin</td><td>Yes (paid M365)</td><td>Group administration, shared mailbox access, full portal</td></tr> </tbody> </table>

---

<a id="bkmrk--15"></a>## Responsibilities Matrix

 <table id="bkmrk-responsibilityprimar"> <thead><tr><th>Responsibility</th><th>Primary</th><th>Backup</th><th>Notes</th></tr></thead> <tbody> <tr><td>Maintain committee group membership</td><td>Anna (staff)</td><td>IT admin</td><td>Add/remove members, verify accuracy</td></tr> <tr><td>Manage shared mailbox permissions</td><td>Anna + IT admin</td><td>IT admin</td><td>Remove predecessor, add successor</td></tr> <tr><td>Ensure `itadmin@` in all groups</td><td>IT admin</td><td>Anna</td><td>Required for archive continuity</td></tr> <tr><td>Monitor membership-change notifications</td><td>Anna</td><td>IT admin</td><td>Power Automate emails = operational signal</td></tr> <tr><td>Troubleshoot delivery/access issues</td><td>IT admin</td><td>Anna</td><td>Includes mailbox permissions and group settings</td></tr> </tbody> </table>

---

<a id="bkmrk--17"></a>## SOP: Add a Person to a Committee Mailing List

1. Confirm committee and target group address.
2. Verify whether person is internal staff or external volunteer.
3. Add to the correct Microsoft Group membership.
4. Confirm `itadmin@` remains a member.
5. Verify Power Automate sends membership-change notification.
6. Ask requester to test delivery (or send a test message).
 
---

<a id="bkmrk--19"></a>## SOP: Remove a Person from a Committee Mailing List

1. Confirm removal request and effective date.
2. Remove member from the Microsoft Group.
3. Verify Power Automate notification is received.
4. If person held a role, check related shared mailbox permissions.
 
---

<a id="bkmrk--21"></a>## SOP: Leadership Transition for Role Inbox

1. Identify affected role mailbox (e.g., `accchair@`).
2. Remove outgoing person's mailbox permissions.
3. Grant incoming person's mailbox permissions.
4. Validate that incoming person can open the shared mailbox from their own account.
5. Keep address and historical content in place for continuity.
 
---

<a id="bkmrk--23"></a>## SOP: New Committee Creation

1. Create new Microsoft Group for the committee.
2. Add initial committee members.
3. Add `itadmin@` as member for archiving.
4. Ensure membership-change notifications are active.
5. Record the group in the committee/group inventory.
 
---

<a id="bkmrk--25"></a>## Governance Rules

- Every committee must have exactly one official mailing-list group.
- Every committee group must include `itadmin@`.
- Shared mailbox addresses represent roles and must not be treated as personal identities.
- Access to shared role inboxes must be updated promptly on leadership change.
- Membership changes should be performed by staff owner (Anna) or IT admin only.
 
---

<a id="bkmrk--27"></a>## Recommended Recordkeeping

Maintain a simple inventory table (in the wiki or internal operations file) with:

- Committee name
- Group email address
- Current chair role mailbox (if applicable)
- Current permission holders
- Last membership review date
- Last updated by
 
<div id="bkmrk-this-makes-volunteer">This makes volunteer/staff handoff much easier.</div>---

<a id="bkmrk--29"></a>## Common Issues and Checks

### Person does not receive committee emails

- Member exists in correct Microsoft Group
- Email address is correct
- Sender used the correct group address
- Recent change triggered notification (confirms update happened)
 
### New chair cannot open role mailbox

- Shared mailbox permission was granted to the person's licensed account
- User is opening mailbox from their own account context
- Predecessor access was removed (to avoid confusion)
 
### Missing archive history

- `itadmin@` is still a member of the affected group
- Group delivery settings have not been altered
 
---

<a id="bkmrk--31"></a>## Handoff Checklist (Staff / Volunteer Transition)

- Review all committee group memberships for accuracy.
- Verify all active chairs/executive roles have correct shared mailbox access.
- Remove stale permissions from former role holders.
- Confirm `itadmin@` is in every group.
- Confirm membership-change notification flow is working.
- Update inventory table and date-stamp the review.
 
---

<a id="bkmrk--33"></a>## Key Contacts and Ownership

 <table id="bkmrk-rolecontact-group-me"> <thead><tr><th>Role</th><th>Contact</th></tr></thead> <tbody> <tr><td>Group membership owner</td><td>Anna (staff)</td></tr> <tr><td>Technical owner / escalation</td><td>IT admin</td></tr> <tr><td>Archive mailbox</td><td>`itadmin@` (not actively monitored)</td></tr> </tbody> </table>

<div id="bkmrk-if-ownership-changes">**If ownership changes, update this section immediately.**</div>---

## Related Resources

- [M365 Email Building Blocks](/books/shha-it-help-guide/page/m365-email-building-blocks) — understand the four email patterns (personal mailbox, shared mailbox, mailing list, alias) and when to use each
- [SOP: New Users, Mailboxes &amp; Groups](/books/shha-it-help-guide/page/sop-new-users-mailboxes-groups) — step-by-step admin procedures for creating users, shared mailboxes, groups, and aliases

# M365 Email Building Blocks

SHHA uses four distinct patterns for email addresses in Microsoft 365. Before requesting any new address, understand which pattern fits your need. This page is the reference for anyone planning new committees, roles, or special-purpose addresses.

## The Four Patterns at a Glance

<table id="bkmrk-patternwhat-it-isexa"><thead><tr><th>Pattern</th><th>What it is</th><th>Example</th><th>When to use it</th></tr></thead><tbody><tr><td>**Personal mailbox**  
`first.last@sandiahomeowners.org`</td><td>A licensed M365 account owned by one person. Has its own login, calendar, OneDrive, etc.</td><td>`anna.smith@sandiahomeowners.org`</td><td>Office staff and IT admins who need to *log in* to Microsoft 365 and perform admin tasks. **Costs a license.**</td></tr><tr><td>**Shared mailbox**  
`role@sandiahomeowners.org`</td><td>A mailbox tied to a *position*, not a person. Multiple licensed users can open it from their own account. Retains full email history across holders.</td><td>`president@sandiahomeowners.org`  
`cscchair@sandiahomeowners.org`</td><td>Any role where you need: (a) a stable address that survives personnel changes, (b) email history inherited by the next holder, (c) the ability for multiple people to send/receive as that address.</td></tr><tr><td>**Mailing list (Microsoft Group)**  
`committee@sandiahomeowners.org`</td><td>A distribution group. Email sent to the address is delivered to every current member — including external guests who have no M365 license.</td><td>`csc@sandiahomeowners.org`  
`shha-all@sandiahomeowners.org`</td><td>Any group of people who need to receive the same email. Most committees have one. **No license cost** for external members.</td></tr><tr><td>**Alias**  
*(additional address on an existing mailbox or group)*</td><td>An extra email address that delivers to an existing mailbox or group. Not a separate mailbox — just an alternative address for the same destination.</td><td>`wildfire@sandiahomeowners.org` → delivers to the ESC group or a specific shared mailbox</td><td>One-off or special-purpose addresses (task forces, events, topical inboxes) where you do **not** need a separate mailbox with its own history. Use when you want a memorable address that maps to something that already exists.</td></tr></tbody></table>

## Which Pattern Do I Need?

Walk through these questions when planning a new email address:

1. **Does one specific person need to log in to M365 and perform admin tasks?**
    - Yes → **Personal mailbox** (requires a license; talk to IT admin)
    - No → continue
2. **Does the address need its own persistent inbox that survives personnel changes?**
    - Yes → **Shared mailbox**
    - No → continue
3. **Does the address need to deliver to a group of people?**
    - Yes → **Mailing list (Microsoft Group)**
    - No → continue
4. **Do you just need a convenient address that routes to an existing mailbox or group?**
    - Yes → **Alias** on the appropriate existing mailbox or group
    - No → talk to IT admin to figure out the right approach

## Combining Patterns

For a full committee setup you typically create **all three**:

<table id="bkmrk-whatpatternexample-f"><thead><tr><th>What</th><th>Pattern</th><th>Example for a new "Wildfire Preparedness" task force</th></tr></thead><tbody><tr><td>Committee mailing list</td><td>Microsoft Group</td><td>`WPC@sandiahomeowners.org`</td></tr><tr><td>Chair inbox</td><td>Shared mailbox</td><td>`WPCChair@sandiahomeowners.org`</td></tr><tr><td>Friendly alias (optional)</td><td>Alias on the group</td><td>`wildfire@sandiahomeowners.org` → delivers to `WPC@`</td></tr></tbody></table>

You generally do **not** need to create personal mailboxes for the members — external volunteers receive group email at their personal addresses (Gmail, Yahoo, etc.) at no license cost.

## Archive Rule

Every mailing list (Microsoft Group) **must** include `itadmin@sandiahomeowners.org` as a member. This is the archive account that preserves all committee email for continuity and records. It is not monitored for support.

## Cost Summary

<table id="bkmrk-patternlicense-cost-"><thead><tr><th>Pattern</th><th>License cost</th></tr></thead><tbody><tr><td>Personal mailbox</td><td>Requires a paid M365 license</td></tr><tr><td>Shared mailbox</td><td>Free (up to 50 GB; no license unless it exceeds the limit)</td></tr><tr><td>Mailing list (Group)</td><td>Free</td></tr><tr><td>Alias</td><td>Free (added to an existing mailbox or group)</td></tr></tbody></table>

## Where to Go Next

- **Need to create a new user or shared mailbox?** See *SOP: Add a New User &amp; Create a Shared Mailbox* (next page in this chapter).
- **Need to add/remove members from an existing group?** See the SOPs in *M365 Email Groups, Role Inboxes &amp; Responsibilities*.
- **Not sure what you need?** Email <ithelp@sandiahomeowners.org> with a description of the goal and IT admin will recommend the right pattern.

# SOP: New Users, Mailboxes & Groups

This SOP is written for SHHA staff who are comfortable with basic Microsoft admin work and need a reliable step-by-step process for setting up new groups, shared mailboxes, and related addresses.

**Start here every time:** [admin.microsoft.com](https://admin.microsoft.com)

---

## Quick Start: What Are You Trying to Set Up?

<table id="bkmrk-if-you-need...go-to-"><thead><tr><th>If you need...</th><th>Go to this section</th></tr></thead><tbody><tr><td>A new task-force or committee mailing address that sends to all members</td><td>[SOP A: Create a Microsoft 365 Group (Mailing List)](#bkmrk-sop-a%3A-create-a-micr)</td></tr><tr><td>A role inbox for a chair or lead (keeps history when people rotate)</td><td>[SOP B: Create a Shared Mailbox](#bkmrk-sop-b%3A-create-a-shar)</td></tr><tr><td>A friendly one-off address like wildfire@sandiahomeowners.org</td><td>[SOP C: Add an Alias](#bkmrk-sop-c%3A-add-an-alias-)</td></tr><tr><td>An internal staff account with first.last@sandiahomeowners.org login</td><td>[SOP D: Add a Licensed User](#bkmrk-sop-d%3A-add-a-new-lic)</td></tr><tr><td>An external volunteer using Gmail/Yahoo/etc.</td><td>[SOP E: Add an External Guest](#bkmrk-sop-e%3A-add-an-extern)</td></tr></tbody></table>

---

## Task Force Fast Path (Most Common New Setup)

For a new short-term task force, the normal pattern is:

1. Create a **Microsoft 365 Group** for the task-force mailing list.
2. Add members (including external guests) and always include `itadmin@sandiahomeowners.org`.
3. Create a **Shared Mailbox** for the task-force lead/chair if they need role continuity.
4. Add an optional **Alias** (for example, `wildfire@sandiahomeowners.org`) if a friendlier address is useful.
5. Test email delivery and update the Quick Links directory.

If you only need one address that emails the whole task force, do **SOP A** only.

---

## SOP A: Create a Microsoft 365 Group (Mailing List)

**Use this for:** any committee/task-force address that should email all members.

**Menu path:** [admin.microsoft.com](https://admin.microsoft.com) → **Teams &amp; groups** → **Active teams &amp; groups** → **Add a group**

### Step-by-step

1. Open [admin.microsoft.com](https://admin.microsoft.com) and sign in.
2. In the left menu, click **Teams &amp; groups**.
3. Click **Active teams &amp; groups**.
4. Click **Add a group**.
5. Select **Microsoft 365** as the group type, then click **Next**.
6. Enter: 
    - **Name**: Full task-force name (example: Wildfire Preparedness Task Force)
    - **Description**: Short purpose statement
    
    Click **Next**.
7. Add at least one **Owner** (usually office staff), then click **Next**.
8. Set: 
    - **Group email address** (example: `wildfiretf` → `wildfiretf@sandiahomeowners.org`)
    - **Privacy**: usually **Private**
    - Leave "Create a team for this group" **off** unless Teams is explicitly needed
    
    Click **Next** then **Create group**.
9. Open the new group, then go to **Settings**.
10. **Enable external email:** turn on **Let people outside the organization email this group**.
11. **Enable inbox delivery:** turn on **Send copies of team emails and events to team members' inboxes**.
12. Go to **Members** → **Add members**.
13. Add all task-force members (internal and external as available).
14. **Required:** Add `itadmin@sandiahomeowners.org` as a member for archive continuity.
15. Send a test email to the new group address and confirm delivery.

### Done checklist

- Group exists
- Owners added
- All members added
- External email enabled
- Inbox delivery enabled
- `itadmin@` added
- Test email delivered

---

## SOP B: Create a Shared Mailbox (Chair/Lead Inbox)

**Use this for:** role inboxes that must persist when people rotate (chair, lead, coordinator).

**Menu path:** [admin.microsoft.com](https://admin.microsoft.com) → **Teams &amp; groups** → **Shared mailboxes** → **Add a shared mailbox**

### Step-by-step

1. In admin center, go to **Teams &amp; groups** → **Shared mailboxes**.
2. Click **Add a shared mailbox**.
3. Enter: 
    - **Name** (example: Wildfire Task Force Lead)
    - **Email** (example: `wildfirelead` → `wildfirelead@sandiahomeowners.org`)
4. Click **Save changes**.
5. Open the mailbox details and click **Members** → **Edit** → **Add members**.
6. Add licensed users who should access the mailbox (usually current lead/chair and optional backup).
7. Set **Send As** (or delegation) permissions for the same users.
8. Ask one user to verify in [outlook.com](https://outlook.com) that: 
    - The mailbox appears (or can be manually added)
    - They can receive mail
    - They can send with the shared mailbox in the From field

### Important notes

- Shared mailboxes are role-based, not person-based.
- Do not create separate personal accounts for each chair unless they truly need their own licensed login.

---

## SOP C: Add an Alias (One-Off Friendly Address)

**Use this for:** addresses like `wildfire@sandiahomeowners.org` that should route to an existing group or mailbox.

**Menu path:** [admin.microsoft.com](https://admin.microsoft.com) → select target group/mailbox → **Email aliases** / **Email address** settings

### Step-by-step

1. Decide destination first: should alias route to the **group** or the **shared mailbox**?
2. For group destination: 
    - Go to **Teams &amp; groups** → **Active teams &amp; groups**.
    - Select the group.
    - Open email settings and add alias address.
3. For shared mailbox destination: 
    - Go to **Teams &amp; groups** → **Shared mailboxes**.
    - Select mailbox.
    - Open email settings and add alias address.
4. Save changes.
5. Send test email to alias and verify it arrives in the expected destination.

---

## SOP D: Add a New Licensed User (Internal Staff)

**Use this for:** staff/admin accounts that need a personal Microsoft login (`first.last@sandiahomeowners.org`).

**Menu path:** [admin.microsoft.com](https://admin.microsoft.com) → **Users** → **Active users** → **Add a user**

### Step-by-step

1. Go to **Users** → **Active users** → **Add a user**.
2. Enter name and username (`first.last` format).
3. Generate temporary password and require password change at first sign-in.
4. Assign correct M365 license.
5. Finish adding user.
6. Add user to appropriate groups/shared mailbox access as needed.

---

## SOP E: Add an External Guest (Volunteer)

**Use this for:** most volunteers; avoids paid license cost.

**Menu path:** [admin.microsoft.com](https://admin.microsoft.com) → **Users** → **Guest users** (or Entra invite flow)

### Step-by-step

1. Invite external user with personal email address.
2. Ask them to accept Microsoft invitation email.
3. After acceptance, add them to needed Microsoft Groups.
4. Verify they receive test group email.

---

## Final Validation (Do This Before You Close the Ticket)

- Group email tested
- Shared mailbox tested (if created)
- Alias tested (if created)
- `itadmin@` included in group
- Quick Links directory updated with new addresses
- Requester notified that setup is complete

---

## Where To Go Next

- [M365 Email Building Blocks](/books/shha-it-help-guide/page/m365-email-building-blocks) for choosing the right pattern first
- [M365 Email Groups, Role Inboxes &amp; Responsibilities](/books/shha-it-help-guide/page/m365-email-groups-role-inboxes-responsibilities) for governance and handoff rules
- [Quick Links &amp; Directory](/books/shha-it-help-guide/page/quick-links-directory) to keep the address list current