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
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.
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.