of the
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):
The Good
- 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.
The Bad
- 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?
The Ugly
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.
Good again
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.
I think we really need some clarity on:
based on or replicates the functionality of entities
I license the Sales App only but I create a custom Order Issues entity. Customer phones up and an order issue is logged by a CSA. Missing parts, damaged or late delivery etc. someone investigates and then we can resolve the order issue by sending a replacement, issuing a credit, or explaining to customer.
Oh no – I’ve created an Incident tracking system, I’ve breached my license.
I’m no lawyer (obviously, I’m a CRM consultant) but from my limited understanding of the law you can’t impose such vague contract terms and expect a court to enforce them.
Exactly, Andrew, exactly. Though, if you find yourself in a position where court decision is required to enforce some undertaking between you and Microsoft, I don’t envy you, to be honest 🙂
The intent is clear – to stop people purchasing team members licenses and then replicating OOB CRM functionality. But it needs to be expressed better.
I think there are two possible tests to determine if you have breached the ‘intent’ of the licensing.
1. If it smells like a duck, walks like a duck, looks like a duck it probably is a duck.
2. If you didn’t build the custom entity how much ‘effort’ would it take your users to adapt and use a OOB entity to do the similar function?
If its obvious or a toss up then you probably are violating the license terms.
In other words if its a tie, the tie goes to Microsoft.
There is also the scenario where you are forced to recreate an entity because the ootb entity just doesn’t cut it. So for example, in our current system we have a custom address entity because the ootb is not able to perform all the functions we need it to perform.
We have definitely replicated the entity but this is due to restrictions on the existing entity. Another grey area because if we don’t replicate the entity then we cannot deliver requirements and to tell a customer that you need to buy a more expensive licence because of a dynamic 365 limitation will not go down well.
I just worked with a Microsoft Territory Manager regarding this question and below is the summary of the response we received:
You are not able to have Team Member licensed users utilizing Custom entities that replicate functionality that is delivered with OOB or MS provided solutions. If you want to replicate functionality that is in Field Service, for example, your only option is to apply Plan 1 licensing to users.
It sounds like Team members is very limited when taking that into consideration.
Thoughts? Arguments? Obviously this makes certain solutions very costly for companies when trying to combine customization and Team member licensing.
I have been looking for clarification on this area since day 1 of Dynamics 365. I have spoken to various people within Microsoft, some are as confused as the rest of us.
This is not just about Partners creating function with like sounding entities, we for example have a situation where a customer wants to record “Projects”. Its a simple register of what they call projects, this is not PSA, but the entity name would ideally be Projects. So we are not replicating function, therefore in my mind we are ok to create this entity and use it with the Team Member licence.
However, in a couple of other situations, the customer does want Project Services Automation, but having looked at the features of the PSA App, they determined that an ISV solution was a better fit.
Talk to the ISVs and they say Team Member is ok for all users, however, by the wording in the Licencing document, I would not agree. Nor does a senior Microsoft Sales Manager.
The ISVs are rightly concerned/angry, as they have been in market years, and now they see their products potentially being increased in price, because the customers will be required to buy the App/Plan licence and the ISV licence.
We have had a number of other detailed questions around the Team Member licence, and the advice from the same Microsoft Sales Manager was that if it is not explicitly covered in the Licencing document then is up to you to decide. He said if there was ever an issued raised, Microsoft will generally side with the customer. So keep that version of the Licencing you used to determine the status close at hand.
It’s not clear if a team member subscripion can execute workflows on demand on custom entities. Do you know if it can be done?
Hi Matias,
As long as the workflows are restricted to the entities team member has access to, you’re fine. What is not ok is to use elevated workflow privileges to do something users wouldn’t have permissions to do, e.g. create a case.
HTH
George
Hi guys,
I hope my message finds someone 🙂
Regarding the topic of this post, I have an issue myself. Thanks in advance for reading.
I work on a project where I want to allow Team-member-licensed users to input their activity in a simple form comprising the following fields:
– account (look up)
– project (look-up to a custom entity where projects are created with a very simple form, nothink like the OOTB “project” entity)
– type of task and/or phase (option sets or custom entity look-ups, dunno yet)
– subject of the user’s task
– time spent
Other users would have the sales license.
Do you think it will be compliant? I am leaning 90% towards yes but we are never too sure. 🙂
Many thanks for your help! 🙂
Cheers
You can do that with a team member license
thanks!
This is a very interesting discussion thread since I’m trying to find out about this myself.
My question is: does it apply also to the PowerApps Plan 2 license released recently?
I’m planning on developing a model-driven app that replicates a very light version of a CRM so customers can take a lighter intro into the platform and then upgrade to the 1st party apps if they want more. However, I’m not sure whether I can replicate entities such as opportunity or incident by using custom entities under the PowerApps Plan 2 licence or not…
Funny thing is this is exactly what a company has done with this product:
https://rapidstartcrm.com/
They explained on a video on the Business Application Summit (2018) how they did it (model-driven app and P2 license) so it might seem possible…
But I’m not sure 🙁
Does it apply to PowerApps P2? Yes and no. Gist of P2 would be the same but the intent is totally different. P2 is a platform license. P2 is less restrictive than the team license but it won’t have some of the UX features that team member will get, e.g. email sync. Hope it makes a bit of sense but expect more clarifications coming out shortly.
As far as Rapid Start is concerned, as far as I know, they are not replicating Dynamics 365 functionality, as far as I’m aware. They are using 1st class entities available, i.e. incidents, opportunities, etc.
This grey area is now gone with todays changes – see my blog here for my take on the new licence changes.
https://dynamics365northernireland.com/2018/10/01/dynamics-365-ce-licensing-guide-changes-october-2018/