Unified Service Desk (USD) can be combined with PowerApps! But why would I want to do this and how could it be achieved?

In my opinion including PowerApps in USD can be a very useful / powerful feature.

Imagine you need a custom form within USD. You have several options, firstly you could use a “CRM” form. But a CRM form might not provide exactly the interface you require. Next we have USD forms, these can be really useful for simple notifications but adding conditional logic can be challenging. Normally when these approaches aren’t ideal your only remaining option would be to develop a custom hosted control.

Custom hosted controls have many advantages! Including the facts that they perform well and can be customized to provide exactly the experience you wish to deliver to your users. But they do need to be “developed”! Meaning someone with .net skills will need craft your solution, this development takes time.

I therefore investigated the concept of consuming PowerApps directly within Unified Service Desk, as this might provide a new alternative. One that would allow me to create a powerful interface quickly without the need for custom code.

I can think of many reasons to leverage PowerApps within USD. Some reasons include;

1. I’ve often needed to create a custom approach to verification of a customer. Having loaded a contact we typically need to verify we are speaking to the correct customer.
   
2. Agents Scripts are great but what if you needed a simple approach to achieve a more graphical / flexible layout.
   
3. You might simply want to reuse existing PowerApp within USD.
   
4. PowerApps have many connectors for SharePoint, Outlook, Excel, OneDrive etc etc. Being able to leverage these in USD might be very powerful.
   
5. PowerApps “play nicely” with Flow. Making it easy to leverage Flow workflow capabilities directly in USD.
   
6. And many more.
   

As an experiment / proof of concept I’ve created a simple PowerApp to help verify I’m speaking to the correct customer. In my proof of concept I presented the operator with a number of fields. The operator would be expected to tag that the customer has given the correct answer to at least three of five options. Only after selecting these three fields will a submit button become enabled. In my proof of concept, clicking submit would load the agent script. Meaning we could then continue with the call. (Alternatively, the user would enter a failure reason and clicking submit might end the session etc.)

At the end of the day PowerApps have been designed to work with a phone or tablet form factor. But as you can see below you can still display them within USD.

Above you can see that I placed my PowerApp in the RightPanel in USD. I have also experimented with using floating panels (shown below) and the LeftPanelFill. If you opt for these display panels you may need a use additional actions to size and position the screen in a pleasing way!

So how can we achieve this?

In this post I am not going to attempt to explain how to build the PowerApp! I’ll assume you have a basic understanding of PowerApps and USD. But I will show the alterations I did to my PowerApp to be able to integrate it within USD. And explain the challenges I faced.

Initially I generated a default PowerApp connected to my Dynamics 365 instance and the contact entity. I could have created App from scratch but creating a default simply gave me a template to work from. This default App provided me with three forms, a browse screen, detail screen and an edit screen. For my example, I didn’t need the edit screen. So I removed that! However keeping the browse screen was really useful. I never intended on showing the browse screen in USD but keeping it means I can test my PowerApp outside of USD. Being able to do that save me loads of development time.

Challenge One – On Start

Having the browse screen is great but this highlights my first challenge. Getting the PowerApp to start in context of the record currently selected in USD. This was essential as I wanted my PowerApp to show within a session in USD.

When my PowerApp is started from within USD I want to pass in a parameter containing the GUID of the currently selected contact. I could then use that to navigate to that contact in my PowerApp.

On the browse screen, under the actions menu you will find an “On start” option. We can use this to lookup a contact when a parameter is provided. You can see below that I added a formula to the “OnStart” of my browse screen. If formula finds a parameter it will look up the contact and navigate to my detail screen.

If(!IsBlank(Param(“ContactGUID”)),Navigate(DetailScreen1, Fade, {Item: LookUp(Contacts, contactid = Lower(Param(“ContactGUID”)))}))

Challenge Two – Keeping the Browse Screen working

As already mentioned, I wanted to keep my browse screen working. Users would never use it but having it meant I could test and develop my PowerApp outside of USD. For this I needed to make a small change to the “next” arrow on my browse screen. On start my lookup would have loaded the required row into a record called “Item”. Therefore clicking the next arrow needed to assign the correct row to the same “Item” record. I altered the “OnSelect” action of my arrow to contain the formula shown below.

Navigate(DetailScreen1, ScreenTransition.Cover, {Item: ThisItem})
 

Below you can see how I applied this formula in my PowerApp.

Challenge Three – Using my Item record in my Detail Screen

Next I built my detail form. Initially I started off with a default form but actually I re-created this pretty much from scratch. I obviously had to add multiple controls to my form and build my required logic. (None of which I will detail here!)

But it might be worth noticing how I referenced the Item record created from my Browse Screen. Below you can see one simple example, here I have a label control and the text property has been set to “Item.fullname”. I used the same approach to reference all of the fields I required. Such as “Item.birthdate” etc etc.

Challenge Four – Triggering an event in USD.

Next I wanted drive functionality ion USD when someone clicked my submit button. I opted to do this by creating a custom event in USD. An alternative approach would have been to trigger an option. I favoured the event approach as I felt it gave me more options.

Here I added a formula to the “OnSelect” action of my submit button. My formula is shown below;

If(Passed>=3,UpdateContext({Verified: "Passed"}),UpdateContext({Verified: "Failed"})); Launch("http://event/?eventname=Verified&Status=" & Verified & "&Text=" & TextInput1.Text & "&Passed=" & Passed)
 

Your formula will probably look different to this! I actually had a count of the number of options the user had selected. So the first part of my formula is a condition to decide if a pass or fail had been record. The part of the formula that actually triggers my event in USD is shown separately below. In this you can see that my event was called “Verified”. The command I used to trigger the event was a “Launch” action. This constructs a url to trigger a custom event called “Verified”. I also passed several parameters, included a status, any comments the agent had entered and a count of the number of passed items.

Launch("http://event/?eventname=Verified&Status=" & Verified & "&Text=" & TextInput1.Text & "&Passed=" & Passed)
 

And below you can see how I added this formula to my OnSelect action.

Changes needed in USD.

So I had created a PowerApp that would accept a GUID as a parameter, navigate to that record and could return an event to USD. Now I needed to make a number of changes in USD to consume this application. I am going to assume you understand USD! So here I will only explain the basic / key changes I made.

• Step One – Create a Hosted Control
• Step Two – Create an Event
• Step Three – Create a Navigate Action

Step One – Create a Hosted Control

Like all good USD changes, first I needed a hosted control. This would be the tab that I wanted to hold my PowerApp.

I called my hosted control “PowerApp Contact Verification”. You could obviously use any name.

Importantly my component type is “Standard Web Application”.

Also notice that I decided to use “RightPanel” for my Display Group.

In my example “Application is Global” was left unchecked. As I want my PowerApp to load within my session. You could of course use a PowerApp as a global tab!

Step Two – Create an Event

Next I wanted a custom event that the submit button in my PowerApp would trigger. I called my event “Verified”, obviously you could use a different name. Below you can see that I simply used the “ADD NEW EVENT” button to add my event.

Tip: Having created your event you will then add one or more actions to trigger other “stuff”. In my simple example, I added one action that would load my agent script. Notice that I did add a condition which would only do this if my event contained a parameter giving me a status of passed. This is only a proof of concept. In a production version I would probably add several other actions. For example, I’d wat to consider what should happened when eth status was “Fail”. I would also probably add a CreateEntity action to log that the verification has happened.

Step Three – Create a Navigate Action

Next I created a navigate action to load my PowerApp. You’ll need to add this action to the BrowserDocumentComplete event on your contact or possibly in your window navigation rule used to create a contact session.

My action looked like this;

This action is simply navigates to the url used to load your PowerApp. It should be easy to get this by running your PowerApp in a browser and copying the URL. I did however add a couple of things!

url=https://web.powerapps.com/apps/392be483-9d46-471a-96d2-a3eb46bacd11?ContactGUID=[[Contact.Id]+]&HideNavBar=True
 

Notice that I have added ?ContactGUID=[[Contact.Id]+] in my url. This passed the GUID for the current contact to my PowerApp as a parameter. The PowerApp will that use that in its start-up action.

I also added &HideNavBar=True, this was used to remove the navigation bar from my PowerApp. (I did this simply to make the screen look a little better.)

Hopefully the ideas I have explained in this post will inspire you to try using PowerApps with your Unified Service Desk application. Enjoy.