[TIPS] Difference: Owner Team vs Access Team

 

[TIPS] Difference:  Owner Team vs Access Team

Reference: 1  2 

	Owner Team	Access Team
Record Ownership	An owner team owns records	An access team doesn’t own records
Security Role / Priviliege	1.  An owner team has security roles assigned to the team. 2.  The team’s privileges are defined by these security roles. 3.  Team members'  privileges come from their individuals' security roles and their teams' security roles.	1.  An access team doesn’t have security roles. 2.  Team members' privileges come from their individual security roles and owner teams' security roles
Record Access	Full access rights on the records that the team owns.	1.  The records are shared with an access team 2.  The team is granted access rights on the records, such as Read, Write or Append.

Side Note:  Access VS Privilege 

The relationship between an access right and a privilege is that access rights apply only after privileges have taken effect. For example, if a user does not have the privilege to read accounts, that user is unable to read any account, regardless of the access rights another user might grant to a specific account through sharing.

Example:

Below is the hierarchy of an organization.

The salesperson should be able to access all records created by other salespersons who are in the same territory.

Solution: (Using this solution, you can realize more complex requirements, like grant access to salespersons across territories, etc..)

1. Create Access Teams for all salespersons based on their territories.

2. Create a power automate flow to grant access to specific Access Team based on the creator.

Select the desired trigger. For example, "When a record is created, updated or deleted". 

Add an action  "Perform an unbound action" - GrantAccess. 

In the Target parameter, use the pluralized logical name: pluralizedlogicalname(GUID). 

For the PrincipalAccess parameter, needs data in JSON format, as in the below images.  You can type this symbol twice ("@@"), or create a variable for the symbol. 

Initialize and define a variable for the "@" symbol

Compose PrincipalAccess JSON for sharing to a user

Compose PrincipalAccess JSON for sharing to a team

AccessMask:  (Docs article)

Name	Value	Description
None	0	No access.
ReadAccess	1	The right to read the specified type of record.
WriteAccess	2	The right to update the specified record.
AppendAccess	4	The right to append the specified record to another object.
AppendToAccess	16	The right to append another record to the specified object.
CreateAccess	32	The right to create a record.
DeleteAccess	65536	The right to delete the specified record.
ShareAccess	262144	The right to share the specified record.
AssignAccess	524288	The right to assign the specified record to another user or team.

Note - Using the AccessMask of "None" will not revoke access; it will simply make no change to the access of that user/team. You must use RevokeAccess (below) in order to remove access for a user. 

Multiple Permissions

In order to combine multiple permissions, you can separate the access masks by a comma WITHOUT A SPACE. 

{"Principal": {
"systemuserid": "GUID",
"@@odata.type": "Microsoft.Dynamics.CRM.systemuser"
},
"AccessMask": "ReadAccess,WriteAccess,AppendAccess,AppendToAccess,CreateAccess,DeleteAccess,ShareAccess,AssignAccess"}

{"Principal": {
"teamid": "GUID",
"@@odata.type": "Microsoft.Dynamics.CRM.team"
},
"AccessMask": "ReadAccess,WriteAccess,AppendAccess,AppendToAccess,CreateAccess,DeleteAccess,ShareAccess,AssignAccess"}

RevokeAccesswho has access to a record.

Target - use the same values as in GrantAccess

Revokee - specify the user or team to remove access from with proper odata notation.

Check who has access to a record:

Use RetrieveSharedPrincipalsAndAccess.

This function returns a collection of teams and users who have access to this record.