Managing Groups
Was this helpful?
⌘Ctrlk
Groups carry access in most organisations, which makes these components the backbone of provisioning flows.
The standard read, update and delete operations. List Groups accepts an OData filter and the usual Output Type setting.
Creates a group, including dynamic ones.
Membership Rule is what makes a group dynamic. Supplying a rule such as user.department -eq "Sales" switches on rule processing, and membership is then maintained by Entra rather than by your flow.
Visibility sets the group to private, public or hidden membership. Owner IDs assigns owners during creation as a comma-separated list.
Returns the members of a group.
Adds several members at once, given as comma-separated IDs.
Microsoft accepts at most 20 members per request when adding in bulk. Keep this in mind when a flow feeds in a large list, and test with a realistic number before relying on it.
Removes a single member from a group.
Manage who owns a group. This matters more than it looks: a group without an owner has nobody responsible for reviewing its membership, which is why ownerless groups are a standard governance finding.
Checks whether a user belongs to one or several groups, including nested memberships through other groups.
The response tells you whether the user is a member, which of the groups matched, and how many. Nested resolution is the useful part here — a direct membership check would miss access granted through a parent group.
Webhook triggers that react as soon as someone is added to or removed from a specific group.
Together they are the basis for group-driven provisioning: joining the group grants access in the target system, leaving it takes the access away. Building only the first half is a common mistake, and the second half is the one auditors ask about.
Was this helpful?
Was this helpful?