Power Apps has no native function that asks SharePoint whether the current user belongs to a classic SharePoint group. First identify the group type. Microsoft 365 and security groups live in Microsoft Entra ID; SharePoint groups belong to a site. They require different APIs, connectors and permissions.
Most importantly, a membership check used to hide a button is not security. Enforce access at the data source or API as well.
Identify the group before writing a formula
Ask the site owner or administrator for:
- the group name and immutable ID;
- whether it is a SharePoint group, Microsoft 365 group or Entra security group;
- whether nested membership matters;
- whether membership is hidden;
- which operation the check is meant to protect.
A SharePoint site connected to a Microsoft 365 group can map that group's owners and members into site permissions. That does not make every SharePoint group an Entra group.
Option 1: use an Entra group for an app role
For an app-wide role, an Entra security group is often easier to govern than a site-local SharePoint group. An administrator can share the app with the group and grant matching access to the data source.
Membership can be checked through Microsoft Graph. The checkMemberGroups API accepts up to 20 group IDs and returns the IDs in which the directory object is a member. It is transitive, but it needs directory permissions and may return only groups the caller is authorised to evaluate.
A canvas app does not call this API directly without an appropriate connector or flow. Review custom-connector licensing and obtain admin consent for the least-privileged Microsoft Graph permissions.
Option 2: query a SharePoint group through a flow
For a classic SharePoint group, a Power Automate flow can call SharePoint's REST API and return a Boolean or a small role record to Power Apps.
The flow design must define whose identity it uses:
- If it uses the caller's delegated connection, the caller needs permission to query the membership endpoint.
- If it uses an owner or service connection, the flow must validate the caller and restrict the site and group. Otherwise it becomes a privilege-brokering endpoint.
Return a stable shape such as:
{
"isMember": true,
"groupId": 12
}
In the app, handle flow failure separately from a genuine false. A timeout, expired connection or denied API call does not prove non-membership.
Option 3: use an authorised role table
For a small business role that is not meant to mirror platform permissions, store role assignments in a governed SharePoint list or Dataverse table. Give end users read access but restrict who can change assignments.
Filter by a stable identity such as the user's Entra object ID where available, not display name. Email addresses can change, differ in case or be blank for some account types.
This approach is useful for interface behaviour, but the protected data still needs its own permission model.
Avoid this common anti-pattern
Do not download every group member into a collection at app startup and then compare User().Email. It exposes more directory information than needed, becomes stale, performs badly for large groups and often misses nested membership.
Do not treat Office365Users.MyProfile() as a group membership API. It returns profile information, not SharePoint group membership.
Test the real boundary
Test a member, non-member, removed member, guest and denied caller. Test an expired connection and hidden membership if your organisation uses it. Then try the protected operation outside the visible button. If the user can still edit the list or call the flow, the interface check has not secured anything.
For help mapping an app role to the correct permission boundary, join the Power Apps Builders Space.