Auto-Add Users to Group from Form

Overview

This flow listens for new submissions in a Microsoft Form where users request access to a department-specific Office 365 Group. When a response is received, the flow looks up the submitter's profile in Azure AD / Microsoft 365, validates that their department matches one of the supported groups, and (if valid) adds them as a member of the corresponding Office 365 Group. The requestor receives a confirmation email; if the department doesn't match an approved value, the request is rejected with an explanatory message. The pattern is intentionally simple so IT teams can clone it and point it at any internal access-request form.

Use Case

Onboarding and access-request workflows often pile up in an admin's inbox: someone fills out a form, an IT admin reads it, looks up the person, adds them to the right group, and emails them back. This flow removes that manual step entirely for low-risk, attribute-gated groups (e.g. departmental distribution lists, project Teams, intranet site memberships). By keying group membership off the requestor's existing department attribute, the flow self-enforces the policy 'you only get into the group that matches who you already are' without the admin having to look anything up.

The flow is ideal for teams that:

• IT teams running self-service group enrollment for distribution lists or Teams
• Operations teams onboarding new hires into department-specific Office 365 Groups
• Admins replacing manual 'please add me to X' email queues with a Forms-driven workflow
• Organizations standardizing access requests behind a single, auditable form

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Swap the gating attribute

The reference flow validates on Azure AD 'department'. To gate on jobTitle, office location, or a custom extension attribute, change the condition expression and the Approved Group Map keys to match the attribute you prefer.

Add approval routing for high-risk groups

For groups that grant elevated access (e.g. SharePoint admins), insert an 'Start and wait for an approval' action between the condition's true branch and the 'Add member to group' action so an owner has to approve before the membership change is made.

Log every request to a SharePoint list

Append a Create item action after the trigger writing requestor, requested group, decision, and timestamp to a SharePoint list so you have an audit trail outside of Microsoft Forms' response history.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

json(variables('varApprovedGroupMap'))?[outputs('Get_user_profile_(V2)')?['body/department']]

equals(toLower(outputs('Get_user_profile_(V2)')?['body/department']), toLower(outputs('Get_response_details')?['body/requestedGroup']))