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
I just ran into one of the weirdest errors I have seen in my Dynamics CRM/365 carreer, and I have seen a few.
The problem we had was that the case entity had stopped working more or less totally. When trying to open any type of case form either as a normal user or in the form editor, I got a more or less anonymous error message. After a lot of banging my head against the wall and loosing some of my few strands of hair, I finally with the help of Deepesh excellent blog article: https://dynamicsofdynamicscrm.com/2015/09/22/error-resolutionthe-case-of-the-form-which-stopped-loading-in-dynamics-crm/ it got me on the right track. I did some URL-hacking to try to access the form editor directly and accidentaly got to a mixed form editor. Very weird, but it showed that the form itself wasn’t broken, hence there was something wrong further down… probably the fields, just as Deepesh’s error. And after removing all custom fields, I got it working. Then tediously going back and removing them one by one, I found the culprit, a custom Lookup to the Product.
To give you some more background:
When trying to edit any case form, I got the following error:
When trying to create a new case, I got the following error:
And if I downloaded the file, the contents was: (I have hightlighted the part which has some, but only slight relevance)
Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #D856E3CEDetail: <OrganizationServiceFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”> <ActivityId>a3831d4c-6557-4f8a-b558-ba8c01b97e21</ActivityId> <ErrorCode>-2147220970</ErrorCode> <ErrorDetails xmlns:d2p1=”http://schemas.datacontract.org/2004/07/System.Collections.Generic” /> <Message>System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #D856E3CE</Message> <Timestamp>2017-06-29T13:12:03.5384906Z</Timestamp> <ExceptionRetriable>false</ExceptionRetriable> <ExceptionSource i:nil=”true” /> <InnerFault> <ActivityId>a3831d4c-6557-4f8a-b558-ba8c01b97e21</ActivityId> <ErrorCode>-2147220970</ErrorCode> <ErrorDetails xmlns:d3p1=”http://schemas.datacontract.org/2004/07/System.Collections.Generic” /> <Message>System.NullReferenceException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #5CCC57F6</Message> <Timestamp>2017-06-29T13:12:03.5384906Z</Timestamp> <ExceptionRetriable>false</ExceptionRetriable> <ExceptionSource i:nil=”true” /> <InnerFault i:nil=”true” /> <OriginalException i:nil=”true” /> <TraceText i:nil=”true” /> </InnerFault> <OriginalException i:nil=”true” /> <TraceText i:nil=”true” /> </OrganizationServiceFault>
Here are some facts:
We had installed a solution that is an upgraded solution, originally from CRM 4 via CRM 2011 and 2013. Not sure if the field definition from the earlier versions are causing this. Probably not.
I tried switching off all plugin steps. But it didn’t help at all. This is usually what Microsoft support will ask you to do when you have issues why I tried it myself. Always good to try and send this to Microsoft support when registering a support ticket.
I have tried spinning up a clean 8.2 Dyn 365 with no customizations, creating a solution with just the case entity and importing that. It did not work. Not very strange, as the problem was a field that is causing the problem. Adding solutions does not remove anything unless you are using managed solutions with patches etc.
I tried exporting a small solution with just the case forms and removed all custom fields from the customization file manually and reimported it. It did not work, which is not strange either, as the error was not on the form.
I tried creating cases via the API. That did work. I did not use the lookup field that I later found out was the culprit. Perhaps writing something to all fields in the case entity would have generated an error. The reason for doing this was that I wanted to see if I could get an exception in my code that contained more information than what I was getting in the UI. Hence I wasn’t at all happy that it did work.
I tried retrieving cases via the API. That did work. Again, not happy at all.
I tried to manufacture the URL to the form ( https://contoso.crm4.dynamics.com/main.aspx?appSolutionId=%7b<solutionguid>%7d&etc=<entityobjectid, 112 for case>&extraqs=formtype%3dmain%26formId%3d<Guid for the ofrm>%26action%3d-1&pagetype=formeditor) That did not work. No form URL with etc=112 works.
I tried to retrieve the form via the API, that works. Again, not happy, but at least it showed that there probably wasn’t any problem with the form.
I tried to manufacture a weird URL, with the correct form id with the incorrect EntityObjectID. That showed the form, but with the information that the form is for the “other” entity. Weird, but showed that there is actually nothing wrong with the form itself. I could even edit the caseform this way, move fields, remove fields, but not add new stuff. Totally unsupported way of editing a form, but when in love, war and when Dyn365 buggs out, anything is allowed.See below. This proved to be a very useful, as the form seemed for some very strange reason to be involved in this. The way I proved this was that I had an “original”, instance where the error showed and one where I had got it to work, after removing some fields, and removing all unnecessary fields from the main form. After this I created a solution which only imported the form from the non-functioning instance for the case entity and imported it into the working instance. I had not expected the result, but it actually stopped working. With the error described above. So for some reason the form was part of the problem.
A weird Form Editor – the Case form loaded with the Account Entity (EntityTypeCode=1). Be careful when using this, and use at your own risk!
I got the same error as above when I try to open the case form in the normal UI.
When I try to create a new case, I get the error shown in the file “AnErrorHasOccuredWithTimeStampAndLog.png”
As for what happened with the system just before/during/when this error occurred, we were doing customizations on the case form from a spotty internet Connection, and the case for did work before.
In the field-section of the Case entity, I selected “Custom” fields, and I have a notion that most of these errors are probably caused by code which mix up custom lookup fields with built in ones. So I would start by looking at lookup fields based on system entities with custom relationships to case like:
case 1:N case
product 1:N case
account 1:N case
contact 1:N case
pricelevel 1:N case
However you might have several fields that are causing errors (I did), and that might make it very tricky to find what is wrong. Cause once you managed to remove the last field causing the error, and then restore the solution and then remove it again, you will find that you are back to a non-functioning entity, and you will have to work your way through each of the fields, with all their dependencies again, until you find the next one. Hence the methodology becomes
Export solution
Remove fields until you get the entity to work. Document exactly which fields you try and in which order. Always work in the same order. Remove a field, try to open the case, remove the next field, try to open case form, and so on. All the time documenting, which fields and in which order.
When you get the case form to work, import the solution again.
Remove the the field(s) that you know are causing the problems.
If, after this, it still does not work, go to 2.
After I removed the fields, and cleaned the form, I recreated the fields with the exact same schema-names and that worked perfectly. Not sure though how it will work when I export it, I am still not sure what is causing this. Probably some erroneous code in the case logic.
I was able to replicate this error on other instances. So the problem is certainly connected to the solution itself.
So to sum it up. This is most obviously a bug in the Dynamics 365 platform as it should never be able to go into this state. In my case entity the problem was two lookups AND the main “Case” form. After removing the fields and removing all non-necessary stuff from the form by using a URL hack described above, I managed to get it working.
If you run into this, I hope you manage to fix it. It isn’t easy and it will take some time. Hopefully I have given you some pointers.
I am working with a Customer now who is very savvy an wants to do a lot himself, which I generally encourage as this one of the inherent strengths of Dynamics CRM and it would be sad to take it away. Of course we need a healthy discussion on where the line should be drawn on where he should stop configuring and I continue. In larger systems, you also need to take sandboxing/QA instancing into this perspective which of course makes it a bit trickier but this Customer is not so large so they can, at least for the time being, do their configuring directly in the system. It is always a matter of weighing the costs against the benifits.
However, we suddenly ran into a problem when we couldn’t run “Publish All” any more. It just showed a dialog with a cryptic message mentioning object with id [1] missing.
My first thought was that this must be in relation to one specific entity so I started trying to publish one entity at a time (starting with the ones we have changed a lot) and I quite quickly noticed that I got an error when trying to publish Opportunity but not other entities.
I then created a new solution, added Opportunity to this and included all dependencies, and made sure to publish all dependencies Before trying to publish Opportunity, just to make sure that there wasn’t some error in CRM:s causality of publishing. After doing this, I finally go an error message which said something useful, it said that a saved Query of a specifc GUID was missing. This probably meant that this Query was being used on a form in a subgrid and had been removed and when trying to publish, it would not, as the view did not exist.
I opened the form, went through all the subgrids and made sure that the selected view was an existing selection, saved and published the form and it worked. After this publish all also worked.
So the general conclusion is that you should be careful when deleting views as these might be used in subgrids, and the second conclusion is that Microsoft hopefuly will add a dependency blocker that disallows the deletion of a view that is being used in a subgrid.
Recent Comments