How do I Map Users to Dynamics Teams, Security Roles and Entra Security groups

(1) Share

Report

Posted on by RandomDept

700

Good morning, all.

I am trying to store a database of users, so we can perform governance around how they are assigned security roles and permissions to each Environment.

I need to obtain a report to show the following data in each environment: (the plan it to populate a new Table in the COE environment named 'userrolemapping'

Environment Name

Dynamics / Dataverse Team name

The associated Entra Security group name (if it has one, these are usually set as the Base Group for the Environment)

The Security Role assigned to the Team

The following member data of the Dynamics / Dataverse Team:
Full Name

Any direct assigned Security Roles (not provided by a Dynamics / Dataverse Team)

We also have the Centre of Excellence installed so we can take advantage of some of the tables it uses. (I am aware this is being retired, but will continue working with its latest version)

So far, I have had limited success, Using the Centre of Excellence COE admin_environments table to get a list of the active (non Microsoft Teams) environments.
But trying to get a list of users and Dynamics teams is proving difficult.

I've gone as far as using the https://api.bap.microsoft.com/providers/Microsoft.BusinessAppPlatform/scopes/admin/environments?api-version=2016-11-01&`$expand=properties endpoint to return the environment names (OR successfully used the COE admin_environments table to do this..either or work.

I was originally trying to use the systemusers table in every environment to get the user list, but after way too long discovered this table is inaccurate.

Then the Dynamics Endpoint for the Dynamics / Dataverse Teams
$teamUrl = "$baseUrl/api/data/v9.2/teams?" +
"`$select=name,teamid,teamtype,azureactivedirectoryobjectid&" +
"`$expand=teammembership_association(`$select=systemuserid,fullname,internalemailaddress,azureactivedirectoryobjectid,isdisabled)," +
"teamroles_association(`$select=name,roleid)"

I then used the Dynamics API to obtain the Security Roles in an Environment.
https://$baseUrl/api/data/v9.2/roles

And the Dynamics API to obtain the
https://$userRoleUrl = "$baseUrl/api/data/v9.2/roles($($role.roleid))/syst
emuserroles_association?`$select=systemuserid,fullname,internalemailaddress,azureactivedirectoryobjectid,isdisabled"

Then Graph API to get the Entra Security Groups and confirmation of user membership.

I'm still seemingly getting incorrect data, where I see users listed in environments they do not belong..so that is 100% an error with my script..

Reducing to a single environment, is there a Power Automate, COE table or other method to easily return a list of users in an environment, their roles and or dynamics membership?

Thank you.
V

Categories:

General topics

Building flows

I have the same question (0)

All responses (6)

Answers (0)

Sort by

Suggested answer

sannavajjala87 515 Super User 2026 Season 1 on at

Like
a
(1)

Report
Copy link

Link copied!

Hi ,

I wouldn't rely solely on the "systemusers" table, as it can include users that have been provisioned historically and may not reflect current effective access. For governance reporting, I'd use the Dataverse Teams and Roles tables as the primary source, then enrich that data with Microsoft Graph to resolve Entra group membership. Also, be sure to query direct user role assignments separately, as those won't be captured through team membership alone.

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(0)

Report
Copy link

Link copied!
For this type of governance reporting, I would recommend not relying on the systemuser table alone as the source of truth for environment membership. While it

contains user records, it often includes:

Disabled users

Previously provisioned users

Users who no longer have access

Users who have never been assigned a security role

This is why you may be seeing users reported in environments where they do not effectively have access.

Use a combination of:

CoE admin_environments for environment inventory.

Dataverse Teams + Team Membership + Team Roles for access inherited through teams.

Direct User Role assignments for individual permissions.

Microsoft Graph for Entra Security Group mapping.

Treat a user as belonging to an environment only if they have a direct security role or are a member of a role-bearing team.

This will give you the most accurate and supportable governance report while avoiding the inaccuracies that can arise from using the systemuser table alone.

Was this reply helpful? Yes No
MB-15120439-0 4 on at

Like
a
(0)

Report
Copy link

Link copied!

@11manish Thank you.

Are there any specific tables, you could point me toward or will I need to use bapi endpoints?

Thank you.

RD

Was this reply helpful? Yes No

Suggested answer

11manish

3,333 on at

Like (1)

Report

Copy link

Link copied!

For the security-role and team-mapping portion, you do not need BAP APIs. Dataverse tables (systemuser, team, role) and their relationships are sufficient.

Use the BAP Admin API or CoE admin_environments only to discover environments, and use Microsoft Graph when you need details about the Entra security groups

associated with Dataverse teams

Purpose	Table
Users	systemuser
Teams	team
Security Roles	role
Business Units	businessunit
Team Membership	teammembership (via association)
User ↔ Role Mapping	systemuserroles (via association)
Team ↔ Role Mapping	teamroles (via association)

Was this reply helpful? Yes No

MB-15120439-0 4 on at

Like
a
(0)

Report
Copy link

Link copied!

@11manish

didn't you mention the systemuser table was a bad source earlier?

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(0)

Report
Copy link

Link copied!

Good catch. The nuance is:

I said systemuser is a bad source of truth for determining who actually has access to an environment, not that it's a bad table altogether.

So the earlier advice still stands: don't use systemuser as the primary source for environment membership, but absolutely use it as the source for user details once you've determined that the user has access through roles or teams.

Was this reply helpful? Yes No