In today’s dynamic working environments, it is becoming increasingly common for people that work from different areas within an organization to need access to records from the same entity in Microsoft Dynamics CRM, opportunity records for example. Access teams solve this problem by sharing the records with all the members of the team, regardless of other permission restrictions, in a much different way from Owner Teams.
In taking a deeper look into Access Teams, it will help to contrast this against the traditional Owner Teams in CRM. Owner Teams (Ownership) and Access Teams (Sharing) will be explored at both the individual and team level.
Owner Teams (Ownership)
The typical initial approach for defining access to records for a user or team-owned entity is by user ownership. When assigning records to users, they are granted permissions only to records they own. This provides for a very simple model, yet very restrictive in that only one user is granted permissions through ownership. Due to the CRM user to Business Unit relationship, this record also gets linked to the respective Business Unit.
When assigning records to a team versus a user, you can grant multiple users access to the record via ownership. This overcomes the inflexibility of user ownership by allowing access to any sub-set of users. It’s important to note that ownership information of records does not require any additional storage because it is all contained on the records themselves. This fact, when coupled with the argument that determining access by ownership is faster than sharing, proves it to be a more efficient model.
Following the same user-owned entity example, when the user does not have organization level access to the entity, the system will have to check ownership for access to the record. These checks vary depending on individual or multiple records are being retrieved.
Individual Records
When accessing an individual record, the system will check both the user and any owner teams they are a member of for ownership. All security role information for both the user and owner team will be retrieved from cache and used to compare against the information on the record. If the appropriate permissions are granted, a full retrieval of the record is performed.
Multiple Records
When accessing multiple records, the system will check both the user and any owner teams they are a member of in much the same way as individual records. The one difference is that it will be compared against all of the records from the query and where the appropriate permissions have been granted, a full retrieval of the records is performed*.
*“For efficiency, this is performed within the query to the database server. The list of owner teams a user is a member of that can have ownership read access to the type of record being queried is retrieved in memory within the query as a Common Table Expression. An in memory join to the table of records being queried is performed doing a join on the ownerid column, filtering out any records owned by other users or by teams the current user is not a member of. This allows SQL Server to apply rich query optimization and indexing to perform the query as efficiently as possible and reduce the data returned to the application server to only the results set.”- Scalable Security Modeling with Microsoft Dynamics CRM 2013 by Roger Gilchrist
Design considerations
Some important design considerations should be considered when trying to determine which approach to use. Retrieval times to records using the ownership model grows independent of the amount of data in the system. With the sharing model retrieval times grow in direct proportion to the amount of data shared with the user. Although the pure number of teams in the system does not cause any impact, the number of owner teams a user is a member of can slow down retrieval times.
Access Teams (Sharing)
Whenever talking about the scalability of sharing in CRM, it helps to have an understanding of how it is accomplished. Two tables are involved whenever sharing a record, the SystemUserPrincipal and PrincipalObjectAccess tables.
§ The SystemUserPrincipal table contains the security principal information, the User’s Role, Team, Business Unit and Organization and their relationship to other security principals.
§ The PrincipalObjectAccess (PoA) table stores the sharing rules between the security principals and individual records for each entity. This includes the specific permission's to read, write, assign, share, etc. as well as all inherited permissions from cascading shares.
In order to determine access, the SystemUser table is compared to the SystemUserPrincipal table to understand which records the user has permissions. In the second step, the record set is compared to the POA table to understand what permissions are granted for the records.
Individual Records
When accessing an individual record, access privileges are retrieved and validated before the record is opened. The highest level privileges are determined and access is granted where appropriate.
Multiple Records
When accessing multiple records, all the records that match the query are returned and joined to an in memory table that is created with the records of the type the user can access directly through sharing or indirectly through team sharing and compared and appropriate access granted.
Design considerations
Sharing was designed to fill a gap and not necessarily be the primary method for general access. If sharing is used in large scale deployments, it can result in significant data needs to store the sharing rules. Determining access to a record requires more processing power than ownership-based access. Access teams work well in highly flexible and dynamic business environments, although they cannot be used as resources in Service Scheduling.
Users can be a member of a greater number of access teams than owner teams before any performance impacts are noticed. Multiple access teams can be linked to a single record, allowing different access types to be defined for the same record. Access team types are defined at the form level and applies to all records for an entity type and can be used in conjunction with role- based forms to present different views determined by the users security role.
Lastly, it should not be forgotten to address when to remove an access team or revoke permissions for the team. Even though the records from an entity may be purged, the team will still exist until removed.
Conclusions
Access teams and owner teams each have their own strength's and weaknesses. Hopefully with a greater understanding of each topic, it will be more clear when to use one approach versus another. Keep in mind, that owner teams and access teams can both be implemented to take advantage of the strengths of both models. Access teams cannot own a record, they simply provide access through sharing. In deployments with very large volumes of data, sharing should be carefully considered. In managing the lifecycle of an access team’s existence both the granting and revoking of permissions and the team itself should be considered.
By Customer Effective, A Microsoft Dynamics Partner
