One of the new licenses is Dynamics 365 for Team Members Enterprise Edition, starting at $10 per user per month. As attractive as it sounds, this license comes with some caveats. Before shelling out your credit card and getting this license for all of your users, read the Dynamics 365 Enterprise Edition Licensing Guide, and get a magnifying glass for small print. But here is what I think is important (as inspired by Jukka “Kalsarikännit” Niiranen‘s comments):
- Full Read across all Dynamics 365 Applications. Very nice, no room to misinterpret this one.
- Edit access to Accounts, Contacts, Activities, and Notes. “Glamorized” address book functionality but couple it with Outlook and suddenly it’s quite powerful mechanism for uniform tracking customers interactions in your organization.
- Full access to Knowledge Management, Interactive Service Hub for KM. Nice, ability for everyone to contribute and publish.
- Ability to participate in projects by recording time & expenses. Can apply for projects as well.
- Full access to custom entities as long as they stay within the license restrictions, i.e. no sneaky plugins updating opportunities
- PowerApps access (within the licensed entities boundaries)
- Portal or API access Only: Submit cases and read/update Cases user has submitted. Great for ESS portals where users can submit tickets.
- Edit access, where it’s permitted, is not spelled out. Does that include Delete? What about Append as in create a new lookup field on a contact pointing to a custom entity?
- Granted rights are “for their own use and not for, or on behalf of, other individuals”. “On behalf of” as in “John Unlicensed asked me to update an account”? Or as in “you cannot edit an account owned by another user”?
- PowerApps and API access – overlap is not clear. Looks like I can create a custom mobile app that allows team members to submit cases but am I allowed to create a PowerApp doing the same?
This one is so confusing, it’s worth copying verbatim. “If the custom entity is based on or replicates the functionality of entities included in Microsoft Dynamics 365, or if the entity links to entities included in Microsoft Dynamics 365, then users accessing the custom entity must also be licensed to access the included or replicated entity. For example, users creating an entity that replicates the cases entity for a ticketing system would still require the user to be licensed for cases. In other words, customizations may only be performed against entities users are licensed to access.”
“Based” I understand, “links” I understand, “replicates” – this is so fuzzy I don’t know where to begin. Say, I create “Deal with it” custom entity with a title and a deadline. So far so good. Then I link it to the customer. Is it a ticketing system yet? How about if I add some queuing and deploy workflows to route this item between users. Have I replicated cases yet? Add hierarchical relationship, some status code transition rules. Are we there yet?
As Jukka pointed out, what about custom entities that are clearly out of the contention for now but may overlap with the functionality released by Microsoft in the future? Will you suddenly find yourself in a violation of the licensing agreement?
I can see the intent – nothing new here, this kind of licensing has been around since Microsoft Access 1.0 days – but definition of “replicating” desperately needs to be expanded and explained using more detailed samples.
Team members license is designed as a successor to the ambiguous essential license and, despite some confusion and somewhat fuzzy definitions, it is a huge improvement. My take? Get it for everyone in your organization, make people to share their customer communications via CRM and then see if anyone requires more – and there are plenty of other licenses to choose from.