Teams
In a previous post I mentioned that in some cases a common term may be used by each platform to represent different concepts. Teams fall into this category. Until the release of Dynamics CRM 2013 it was truly “apples and oranges.” This release brought a welcome addition and Microsoft split the generic “team” concept into Owner Teams (the original) and Access Teams (the new kid on the block).
Teams in Dynamics: Owner and Access
Teams in Salesforce: Account and Opportunity
Salesforce Teams
This is the simpler of the two. If you have been following this series, recall my discussion on organizational wide defaults. If the object in question (accounts, for example) has an organizational wide default setting of Public/Read/Write teams are irrelevant since everyone can see and edit every account. The prerequisite to this exercise is the assumption that not everyone is able to read and/or edit accounts or opportunities.
According to the Salesforce definition, “An account team is a team of users that work together on an account. For example, your account team may include an executive sponsor, dedicated support representative, and project manager.” The definition for an opportunity team is similar. In classic sales environments several people may work an account or opportunity. These people, in addition to the owner of the account, have the ability to edit account details, create opportunities and perform related tasks.
Simply put, the account or opportunity owner can choose who he or she wants to work with. This is a simple and effective implementation of sharing records. No setup is required other than activating account and/or opportunity teams. Note that the owner of the record does not change.
Another important point is that these teams are unique to accounts and opportunities. There is no concept of teams that relates to any other objects. Salesforce implements a more traditional record sharing model in all other circumstances.
Ownership
Speaking of record owners, there is a fundamental and significant difference between the two platforms pertaining to sharing and ownership. Salesforce restricts record ownership to a single user. Dynamics on the other hand allows individual users and teams to own an account. Since the platforms approach ownership and sharing differently it is difficult to easily contrast them. If I had to distill it down to a single sentence, Dynamics relies more on record ownership to grant privileges whereas Salesforce focuses on “grouping” records that can subsequently be accessed by users belonging to those groups.
Dynamics Access Teams
Until the release of Dynamics CRM 2013 only what is now called Owner Teams existed. With the introduction of this version the concept of Access Teams was debuted. If my suspicions are correct, Microsoft responded to criticism regarding the work required to implement teams and copied the Salesforce approach. Some of Microsoft’s competitive additions have been less than impressive but that is not the case here. Not only did Microsoft implement easy-to-use teams, but in my opinion it went a step further by making these teams available for all entities.
Just as teams can be activated for account and opportunity objects in Salesforce, access teams may be activated for any entity in Dynamics. Whereas Salesforce provides a fixed template with choices of read or read/write, Dynamics allows the administrator to create team templates. This is a powerful concept. It adds the ability to specify deletion, assignment, sharing and other rights.
A sub-grid using this template and template’s associated view is added to the form. As with any sub-grid, user records can be easily added and deleted. In the background Dynamics creates relationships that implement the template permissions for the given user. Note that a user cannot give rights to team member that he or she does not have.
While this is quite powerful I do see room for improvement. The Salesforce model allows each team member to be assigned permissions to a variety of objects (account, opportunity, case) from a single page. Referring to the first figure, either read or read/write access can be independently assigned.
The Dynamics model forces the administrator to assign a single template to a sub-grid which means that every team member added will have the rights specified in the template. This is an issue when one team member is allowed to delete while another can only edit. One somewhat awkward approach is to add two team sub-grids to a form, one assigned to the delete team template and the other to the edit template. Users would then be added to the appropriate sub-grid.
Dynamics Owner Teams
As previously mentioned this is the original team-sharing approach and has similarities to Salesforce Public Groups. These will be contrasted in a future post. Also note that these are distinct from Dynamics Business Units and Salesforce Roles, yet another level of sharing and security to be investigated.
Up to Dynamics CRM 4.0, all teams were what we now think of as Access Teams, in other words teams could not have security roles and could not own records, but records could be shared with a team. When used for sharing records, they did not have the benefit of the new templates to pre-define the security permissions, or the sub-grid interface for ease of use.
Teams could also be used for non-security things like report segmentation – show me all Leads qualified by members of Team X, or cases owned by members of all Teams I am the manager of.
For some security scenarios with very tight rules and “silos” of records, the only way to achieve the business objectives was often to create huge numbers of teams, share records with those and add/remove users from the teams by hand or programmatically according to sets of rules or custom code (eg buttons or custom sub-grid controls).
In CRM 2011, teams could now have security roles, and could therefore own records. But this added some complexity to the way the security model is evaluated.
In those “silo” scenarios, using many teams with frequently-changing members to share records, performance started to suffer, and in large environments could become a real problem.
In the Polaris release of CRM 2011 Online, we did start to see a model closer to the Salesforce “opportunity team”, and a forerunner of what was to come in 2013. You could manage the “sales team” for an Opportunity in a sub-grid on the form to share the record with other users. But only for opportunities, and not configurable in any way.
So in 2013, teams were separated into owner teams (the new “normal” from 2011) and access teams (back to CRM 4.0 days!). But you can choose the type that meets your needs. For record sharing using the new templates + sub-grid approach, use Access Teams. Also for reporting, escalation paths, and other non-security things, use Access Teams (manually created, no templates or sub-grids) since you don’t need the overhead of having security roles. Use Owner Teams if and only if the teams need to be able to own records directly, again to meet certain security model requirements.
Some more info here: Why Use Access Teams in Dynamics CRM 2013