The team member licensing option is something that has been a subject of debate for quite some time. What can it actually be used for and what not? I have heard “experts” suggesting that it be used for integrations but if your read the Dynamics 365 Licensing Guide, appendix A, you can read all about what Team member licensing is and isn’t. Typical scenarios for Team members are:
Read only users
Users that use only slim parts of the system, and not the “cool” First-Party-App features in Sales, Customer Service, Field Service etc.
Users that just track activities
There are some updates to the details of what a team member can and cannot do, and I think the most important is that a team member cannot CUD (Create, Update or Delete) accounts any more.
How urgent is this? Well, for new instances being created, this will be enforced as of April 1 2020. But for existing instances, it will be enforced on July 1 2020. Hence, you still have some time if you have an exiting org.
You can opt-in to early access updates. Goes without saying that you shouldn’t do in your production system, and probably not even in you dev/test environments since as soon as you have you won’t be able to depoy changes. So, having an out-of-ALM-environment where you can test this might be a good idea.
So, the BIG question is, “Are we compliant?”
Well, there is actually a report that you can generate from the Power Platform Admin Center and I have recorded a video below that shows how you can use that and collate the data with pivoting in Excel.
Working with a Flow to do some text analysis and sentiment analysis on Voice of the customer responses.
The trick, as the payment model is per run, is to trigger it per Survey Response, and not Question Response. Hence the logic has to loop through all the question responses.
The way you create a filter in Flow for the query is to use Odata filters. However, I found that these were a casing nightmare, which those of you who have worked with more, probably also have noticed.
After troubleshooting a lot with different queries in the browser I finally found that the following actually worked. Note that you will have t change the guid to your own.
The tricky part, as you can see, is that the first part of the lookup attribute, is defined in camel-case and the one in the related entity (Survey Response) in lower case.
The part you need in the Flow is the last part, but it is useful to test it directly in the browser to make sure you get the syntax correct.
Its the filter part of the query that you are to enter into the “Filter query” field, and make sure to make it dynamic. 🙂
And this is how it looks in Dynamics 365 CE if you check out the fields. I like to look at them in the list view as I can see the schema name there, which isn’t visible in the Form.
msdyn_SurveyResponseId Lookup from the Question Response Entity. As you can see it seems to be using the Schema name above.
This is the primary field Survey Response. Do note the subtle difference between the fields, that Id is spellt with a capital “I” in the Schema name. Based on the information above, it hence seems to be using “Name” to indicate the field.
Hence based on the above, the supposition would be that the syntax is <Schemaname of the lookup>/<name of field in target entity>
I then did a query to business Unit and I was very surprised to find that it was rather inconsistent and looked like this:
with just the query that would be parentbusinessunitid/businessunitid eq null
Let’s have a look at the fields in Dynamics:
The Parent Business Unit Lookup in Business Unit (Self Referential). Note that the Schema name is Pascal Case.
key field, businessunitid in Business Unit
And as you can see, if we were to follow the syntax set by the example above, this should be:
ParentBusinessUnitId/businessunitid
However, that didn’t seem to work, and as a pragmatist, I have to conclude, somewhat sad, that this doesn’t seem to be very consistent.
My recommendation is hence when working with this:
Do not take any casing for granted
<Schemaname of the lookup>/<name of field in target entity> is probably correct for most custom fields/entities.
Many older entities and fields, like the businessunit shown above, has been there since CRM 1.0 or at least 3.0, if I remember correctly and hence the syntax might be different.
Test your queries directly in the browser like I have shown above.
Good luck with your Flows.
And if you know Swedish, make sure you check out my colleague Martin Burmans article on Flow as well. Not sure how well it turns out in translation. https://www.crmkonsulterna.se/flow-i-medvind/
Gustaf Westerlund
MVP, Founder and Principal Consultant at CRM-konsulterna AB www.crmkonsulterna.se
PowerApps or as the new name for it is, Canvas driven Apps, is a very fast low/no-code way of creating applications that can fill in the blanks where Dynamics 365 CE sometimes fit. Can for instance be when there is a mapping entity, a complex calendar functionality or even integrations with a camera or other applications directly. These things can be done, some are even supported within the new UI/UCI if you are running it through the tablet/mobile client. However, there is currently no easy way that I have found to just add a PowerApp/Canvas Drive App (I will just call it PowerApp below to make things easier) to Dynamics. But after a chat with my friend, ex MVP and now Microsoft Global Black Belt Carsten Groth (isn’t that a cool name for a team by the way?) he told me that it is possible to embed PowerApps. So I googled a bit a found that no one seemed to have blogged about this (if you have, please tell me in the comments) except for other it concerning other applications like SharePoint. I tried it out and found that it wasn’t that hard at all to embedd a PowerApp into Dynamics 365.
The first thing we have to start with is to create our PowerApp. You can get to this place by browsing to https://web.powerapps.com or clicking the waffle in Office365 and then selecting PowerApps. In my case, I used the Dynamics 365 template and pointed to the Case Entity and did more or less pressed Next-next-finnish. I did replace the field that was shown in the first screen from the Guid of the case to the field “title” as that makes a little bit more sense looking at.
So what I was looking for when creating the PowerApp was the AppId, in this case: “904e3ac1-1e26-4b4b-a384-971485f6709c“
What we then need is the embedding syntax for PowerApps which is: <iframe src=”https://web.powerapps.com/webplayer/iframeapp?source=iframe&screenColor=rgba(104,101,171,1)&appId=/providers/Microsoft.PowerApps/apps/[AppId]” />
You need to replace the [AppId] with your AppId. Also, if you do not specify it, the iframe it will typically render rather small so I would recommend either setting the size of it directly with width and height attributes or using css, the latter being more kosher.
I tried setting an Iframe directly with this in Dynamics 365, but that didn’t seem to work. All I got was a spinner like this:
Spinner which never stops when tried to add PowerApp directly
Not sure why this is.
So, I circumvented it and created a very small html-page like this:
This time, when trying the TestPowerApp.html-page from my local drive, the spinner was quickly replaced by this and then by the App
Then I uploaded this file as a webresource to Dynamics.
Create a webresource with the simple html-page pointing to the PowerApp
After uploading it, in the WebResource screen, you can test the page by clicking on the URL. It should show a webpage with the PowerApp.
The PowerApp running as a webresource in Dynamicws 365
Now you can use this web resource wherever you want. Like directly in a sitemap:
Added PowerApp webresource to the Marketing Area as a Subarea called “Power App Cases”
It should be possible to send parameters to the PowerApp as well making them context aware so that we can create PowerApps that for instance show up within a case and show specific data on that case after you have selected it in Dynamics 365. However, if you look at the iframe syntax you will see that the AppId and stuff is already a parameter and I need to research this a bit more to be able to figure it out. I think that the html web resource probably has to shuffle the query string parameters from Dynamics to PowerApps. I will leave this hanging and hope that someone else in the community catches this ball! Otherwise I will try to figure it out later.
As CDS (common data service) and Modular Driven Apps are the same thing as Dynamics 365, just with less sugar on top, this technique can be used there as well.
If you find anything unclear or have any questions, please leave a comment (moderated).
Gustaf Westerlund MVP, Founder and Principal Consultant at CRM-konsulterna AB www.crmkonsulterna.se
Recent Comments