How Teams and Security Roles Work Together in Microsoft Dynamics 365 for Shared Record Access

Objective:

Here is this article we will see teams and security roles work together in scenarios where multiple users need access to the same records in Dynamic 365.

Microsoft Dataverse offers a comprehensive and adaptable security framework that facilitates the management of access and permissions in the context of business and customer relationships, while also safeguarding data integrity and privacy. However, team-based security presents ongoing challenges, as it encompasses a broad spectrum of user activities and the ownership of business objects, necessitating appropriate security measures. Initially, one might assume that team-based security is akin to user-based security; however, they are fundamentally different.In Dynamics 365, the organization, a user, or a team typically owns the majority of entities—including custom ones—which, in turn, determines the ownership of business records. While there are four types of entity ownership, it is important to note that custom entities have only two forms of ownership.

Business-owned:

• Additionally, the business owns various system entities within the system. These encompass the Business Unit, Calendar, Team, Security Role, and User.

None:

• Although the solution explorer does not display most of them, the system includes numerous entities that do not have an assigned owner. These primarily include intersect entities, which developers establish to support Many-to-Many relationships or scenarios where a parent record governs access. For example, a user or team can only access Opportunity Product records through an associated Opportunity record they own.

Organization-owned:

• Moreover, the organization owns certain system entities within the platform. These entities comprise Article, Article Template, Competitor, Currency, and Web Resource.

User or Team Owned:

• User or team-owned system entities exist within the framework.Because a specific user or team associates with these records, they link them to a business unit and assign designated security roles relevant to that unit. As a result, these entities participate in role-based security measures.

The team plays an integral role in the ownership of the entity. IIn some cases, the system designates a team or business unit as the owner of records and entities instead of assigning them to individual users. By assigning a team as the owner of a unit, it guarantees that all team members possess uniform access and privilege levels throughout.

Security Role:

A security role delineates the manner in which various users, such as sales personnel, gain access to distinct categories of records. To manage data access, it is possible to adjust current security roles, establish new ones, or alter the assignment of security roles to individual users. Each user may possess multiple security roles. The privileges associated with security roles are cumulative; thus, possessing more than one security role grants a user all privileges available across those roles.

Two types of privileges make up each security role: record-level privileges and task-based privileges.

Record-level privileges

• You must specify the tasks a user can perform on the record, including Read, Create, Delete, Write, Assign, Share, Append, and Append To. ‘Append’ means attaching an additional record—such as an activity or note—to an existing record. Conversely, “Append To” allows you to link to a record. For further details, please refer to the section on record-level privileges.

Task-based privileges,

At the conclusion of the form, grant the user the authority to execute particular tasks, including the publication of articles.

Team:

A team consists of a collection of users who collectively share and collaborate on business records. A single user may belong to several teams. Teams facilitate the sharing of business objects and enable collaboration among individuals across various business units.

• Teams grant access to a collective of users. 
• Each team is affiliated with a single business unit, although it may comprise users from various business units. 
• The privileges of the team are determined by specific security roles. 
• A user may be linked to multiple teams. 
• A team possesses complete access rights to the records it owns.

• Owner Team:

• • A team of owners possesses records and has security roles allocated to the Team. The privileges of the Team are determined by these security roles.

• Access Team: 

• • An access team lacks both records and assigned security roles. The privileges of team members are determined by their individual security roles as well as the roles of the teams to which they belong.

Azure AD Security Group Team:

This team functions similarly to an owner team. An Azure AD Group Team has the capability to own records and can be assigned security roles.

Access Team and Share Record:

When opting for an access team strategy rather than an owner team strategy, one essentially exchanges multiple record shares for a single team. In scenarios where ten users need access to a record, you would typically create ten share records in the Principal Object Access (POA) table. However, when you use an access team, you only need one share record because the team—containing all ten users—holds the shared access collectively. This approach yields the same outcome in terms of access. The advantage lies in the reduction of nine share records, replaced by a single team record. I prefer this method over maintaining individual record shares if I can implement it on a larger scale, thanks to its significant performance benefits.

Access teams do not possess security roles; instead, they obtain their security context via record sharing. When a user shares a record, they can specify the privileges associated with that share. This capability is a key reason why access teams do not require security roles. The primary function of the team is to facilitate a collective framework for managing share privileges.

As previously noted, the system manages access teams by automatically creating and removing them. This feature benefits scenarios where businesses create many temporary teams, as the system eventually removes them when they’re no longer needed. While access teams may fulfill this need, it seems uncommon for users to actively remove individuals from an existing team. However, you may opt to carry out this action manually if it aligns with your requirements.

Team and Security Role:

A frequently encountered notion is that “Users inherit security roles from all the Teams they belong to.” While this description generally captures the essence of the process, there are instances where unusual behaviors arise, suggesting that this explanation may not be entirely precise.

I have long held the intuition that the previous description was not the most accurate representation of how this operates. I would rather articulate that “when a User is part of a Team, they can function as if they embody the Team, exercising the rights associated with the Team’s Security Roles, but this is applicable solely to records within the same Business Unit as that Team”.

Conclusion

In summary, this indicates that Security Roles employ a form of “impersonation” in the context of Teams. The Team doesn’t temporarily lend rights to the User; instead, the User’s rights depend on the Team’s location. As a result, access levels and hierarchies like “Business Unit” or “Parent/Child Business Unit” follow the Business Unit linked to the Team.

When a Role assigns the Create privilege at the user level for a specific entity exclusively to a Team, any member of that Team can create records of that type. However, this is contingent upon the member designating the Team as the Owner prior to saving the record. Should they attempt to save the record with themselves listed as the owner, the security model will respond by stating. “You do not possess the authority to create this type of record. However, as a member of a Team, you can act on behalf of that Team to create these records, but only for the Team itself.

The User does not possess the capability to generate records that belong to them. They can temporarily “impersonate” the Team, allowing them to perform all actions that the Team is capable of executing. However, these actions are conducted in relation to the Team’s records. meaning that at the Basic or User level, the Team is considered the Owner. Note that the Security Role editor interface inaccurately labels this level as simply “User.

This concept of “impersonation” can be likened to the notion of having an Avatar . an entity that can navigate a distinct environment on your behalf, equipped with skills and abilities that you typically do not have, such as functional legs or the capability to ride airborne creatures like banshees.

Readmore : Control Data Access in Dynamics 365 with Roles & Teams

Note:

Roles assigned to Teams generally provide extensive access to resources that you intentionally wish to make widely available. For instance, this approach allows all Users to read all Accounts and Contacts within their Business Unit or even across their entire Organization.

FAQ’s