Power Automate on LinkeD365 Blog

Using Power Automate and Graph API to manage External access to Teams

Thu, 06 May 2021 00:00:00 +0000

MCJ and I presented API’s – The most powerful tool, anyone can use! for D365 UG and Swiss Power Saturday recently and I thought it would be good to share the Cloud Flow I created to automate the onboarding of external users to a Microsoft Team.

This is usually an admin driven activity - A team owner will have to type in the email address for each guest they want to add, rather than something you can push to external users and allow them to request access.

By using the Graph API via a Custom Connector, Microsoft Forms and Power Automate, we are able to realise this quickly and save a lot of time and effort in the manual process.

Also, I have been lucky to have this solution accepted as part of the samples in the Microsoft Patterns And Practices initiative, so the Flow, Custom Connector and implementation instructions are available in GitHub here.

TLDR;

I created a Power Automate Cloud Flow which allows an external user to request access to a Team, get approved by the owner of the team, invite the external user to your tenant and add them to the team.

Getting hands on with Graph

The main part of this flow is numerous calls to the Graph API. The Graph API is Microsoft’s standard endpoint to expose and interact with data relevant to your tenant. It includes Microsoft 365 (such as Teams, Exchange, SharePoint, Workspace Analytics), Enterprise and Mobility and even Windows 10 activities and devices. It really should be seen as a single stop shop for anything and everything in your tenant. The only thing it doesn’t expose is D365 data.

There is a Graph connector already available in Power Automate, but it is very limited to Security considerations. Thankfully, the rest of the Graph API abilities are available, but you have to go via a custom connector. You could call these directly via an HTTP request action, but by wrapping the Graph API in a connector, you are enabling other members of your organisation to re-use the connector and security you establish.

Microsoft also allows you to “play” with the Graph API as well, via the Graph Explorer. This web interface shows you all the sample calls you can make and also what permissions you require to call it and allows you to set up a call without using Power Automate or configuring a connector. It really should be the starting point for any Graph Customer Connector.

If things go wrong, it is usually around the permissions. Within the Graph Explorer you can consent to these extra permissions on the fly, but more importantly, tells you what you need to configure in the permissions of your App registration to allow your connector the same access.

Granting Permissions

Now that we understand what permissions that are needed to get at the actions required, let’s jump in and create an Azure App Registration. This allows you to grant rights to a particular application, which presents a client secret and App ID as part of the request. By doing this registration, you establish trust between your app (Custom Connector in our case) and your tenant.

Navigate to https://aad.portal.azure.com and log in. Select Azure Active Directory then App registrations. Select New, give it an appropriate name then hit Register.

In the next screen, record the Application Id, going to need it later. On the left, select Certificates & secrets

Select New client secret give it a name & expiry date and select Save.

Ensure you copy the Value here, you will only be able to see this for a short while, if you navigate away it will be gone. Not a big deal, just recreate the client secret, but you will need it later. Now select API permissions. This will list what permissions this registration has, and by inference, the caller using the client secret/application id.

Select the Add a permission button.

This presents a choice of which API to expose. The first on the list is Microsoft Graph, the one we want.

Select Delegated Permissions (Custom connectors doesnt support Application permissions yet, will run in the context of the person who runs the flow, so use an admin/system account) then type in the permission you want, listed here.

Directory.ReadWrite.All
User.Invite.All
User.ReadWrite.All

Select Add Permissions to return you to the Configured permissions screen, then select Grant Admin consent button. This shortcuts and pre-approves the app.

Leave this tab open and let’s go and define our custom connector.

Defining the Custom Connector

Jan Bakker has done an excellent job of walking you through this, here. His article goes into a lot of detail, so I will just take you through what is needed for this project.

In make.powerapps.com, select the appropriate environment and chose Custom Connectors under Data. Then select New custom connector. You can import from various sources, but we want to create from blank, give it a name then fill out the next page.

On the next screen, there are four tabs, which we need to step through. First the General Tab.

Other stuff is nice to have and you should document your work. Ensure Scheme is HTTPS and Host/Base URL are populated.

Host - graph.microsoft.com
Base URL - /v1.0

Select the Security Tab next, Authentication type is OAuth 2.0. You should be presented with the below screen.

Now, this is where we need to use the values you saved (you did save them?) when you were registering your app up here. Client Id is populated with the Application (client) ID, the Client secret is populated with the Value from the Client Secret grid. Login URL will be populated for you. The Resource URL value should be https://graph.microsoft.com.Select Create Connector now, as you need the Redirect URL, created when you create the connector to put back into your App registration to complete the security process.

I think that this is now standard, but just in case, copy the Redirect URL and go back to your App Registration in Azure AD. Click on the link highlighted.

Select Add a platform then chose Web. Enter the Redirect URL from the Custom Connector. Now we are ready to define the actions for our connector.

Creating the Actions

For our flow, we need 3 actions, Get the owners of a team, Get a user and Invite a User. This is where Graph Explorer and Postman help. You need to establish what you are sending and what you expect back for each action. For example, lets walk through the Get Owners of a team.

Select New Action and Populate General section. The Operation ID needs to be unique and is what appears within Power Automate when you select it.

I usually use the same for each, but be creative and descriptive. Select Import from sample then use the url below as the URL and select Get as the Verb.

URL - https://graph.microsoft.com/v1.0/groups/{teamId}/owners

By placing teamid in curly brackets { } you denote to the custom connector you want to use a parameter in that URL. You can call https://graph.microsoft.com/v1.0/groups/{teamId} (without the /owners) but that will return the detail from the group. In this I want get associated data, hence the /owners.

Select Import. You are returned to the definition screen, where we can see that the request has been populated for us.

We are ready to test our Get Owners now. Update the connector once more then head over to the Test tab. You will have to create a connection if not already done, which prompts you to establish who you are running the connector under (only for testing). Then supply a team id. These can be found by using Graph Explorer to find all teams. Hit the Test operation and if everything is working you will get a 200 response with some JSON in a body showing you all the information about the owners.

To just define the others

Get User

Verb: Get, URL: https://graph.microsoft.com/v1.0/users?$filter=

Invite User

Verb: Put, URL: https://graph.microsoft.com/v1.0/invitations, Body is below, as you need to define a new invite, with the required parameters. The data doesn’t matter, just the parameters that you need to pass.

1
2
3
4
5
6


{
 "invitedUserEmailAddress": "emailaddress",
 "inviteRedirectUrl": "https://myapp.contoso.com",
 "invitedUserDisplayName": "Testy McTest",
 "sendInvitationMessage": true
}

Make sure you test all your actions and lets move on to the Form.

Microsoft Form to capture information

Not going to dwell here, as others are doing a much better job at describing Forms. Basically, a simple form to define First and Last name, the email address and a choice field to define which team the user wants access to.

The teams list will have to be maintained to those that you want the public to be able to request access to.

Finally, lets take a look at the flow.

Power Automate Definition

This Flow is triggered by a new response being submitted against the Form defined above. Next, get the response details.

Next, retrieve all the Teams in your environment. This will return a JSON object which defines an array of Team definitions. We need to filter that to the one the user selected so that we can get the team id.

To do this, I use the Filter Array action, pass in the output from the List Teams and ensure we select where team Name is equal to the team selected (the Which Team? field in my case).

Next, is a compose statement. I do that just to simplify the way the flow works, as the return of filter array is an array, and I just want the first one.

1

body('Filter_array')[0]?['id']

Next, lets get the Owners of the team selected, using the Id just retrieved. This is the first time using the Custom Connector, it is available under the Custom Tab.

Selecting the connector will show the actions or triggers available.

The parameters are those that were defined in the Custom connector, passing in the output from the compose above.

Now, the response back from Get Owners is a JSON object, so next, Parse the JSON so there is a list of JSON objects for the flow to use. All that is needed in the approval that comes next is the email address(es) of the return from the owners call. But the approval needs a semi-colon separated list of emails. To achieve this, firstly use a Select to just return the email address from the JSON object, then join the output to that with a semi colon.

Next, start an approval. This is populated to let the owner know who has asked for access to the team and which team.

Check whether the response is positive. If this was for production, I would probably send an email to the requesting user to let them know that they were denied access. You could also use the response written in the rejection.

In the Yes path, call the Custom connector again to check if the user is already a part of your organisation as a guest user. As the parameter is expecting a query, use the expression below

mail eq ‘Email Parameter from the Form response’

1

mail eq 'Email Parameter from the Form response'

Next, check the length of the returned object from the custom connector. This basically checks if the user already belongs to your environment.

1

length(outputs('GetUser')?['body/value'])

If there is a value in the return, use the return to invite the user to the team.

The User id is returned by using the expression below

1

body('GetUser')?['value'][0]?['id']

On the negative side, firstly invite the user to your organisation by using the final action of the custom connector.

And finally, use the response from your custom connector, the invited user to the team.

Thats it! There is a lot of configuration here, but you can see how you can extend your usage of Power Automate to automate a function usually confined to manual work by the team owner.

Warning

Adding guest users to your Teams is only available if your administrator has configured it. This logic will not override that and will only produce errors if it has been disabled.

Adding to Calendars using Power Automate

Wed, 24 Jun 2020 00:00:00 +0000

D365 Customer Service and Field Service both use Calendars associated with resources to schedule working time. This is accessible via the resource calendar and typically relies on the individual working a set time frame each week. Fiona works Monday to Friday, 8-5.

When you are working with volunteers, this doesn’t work. Each volunteer will have an inconsistent schedule, with most of the time not being available. Rita has just volunteered for a couple of hours next Thursday.

A recent client project to improve their scheduling of resources and was definitely in the second scenario. It wanted volunteers to sign up for times using simple time entry on a portal and transfer these times to the scheduling board.

As Calendar is available as an entity, my initial thoughts that these would be a simple integration using Flow, unfortunately, not. This post details my findings and how I achieved creating sporadic “On Time” in Field Service or Customer Service.

All credit for this discovery goes Dave Bostock, my colleague at Avanade, but judicious use of F12. Thanks to Jason Almeida and Rob Dawson for their support and experience to nudge me to the solution.

TL;DR

How to create calendar entries in D365 for resources using an unbound action in Power Automate.

Manual configuration of Calendar Entities

Every bookable resource has a calendar associated with them. This Calendar has several rules which establish the working pattern for the resource. A rule, normally, would say “This resource works Monday to Friday, 9 to 5” or something similar.

From the Resource, you can get to a calendar view by selecting Show Work Hours, highlighted below. It may also be available as a tab on the main form, depending on whether you are using Field Service or not. For me, I am still using the Customer Service version.

Top left, you can alter the default rule for the user by adding a new weekly schedule, add an update to a single day or add time off for the resource.

Selecting New Weekly Schedule and populating the next screen is the standard way resource get a weekly schedule.

For volunteer management, resource tends to have a blank calendar. This is done by deleting all the calendars associated with the resource. From there, a volunteer would sign up for periods or shifts. This, on the face of it, just sounds like data entry, easily achieved via Powe Automate.

Creating Rules via Power Automate

If you use either of the Common Data Service connectors to create a calendar rule, you will be presented with this error.

This is because calendarrule is not a real entity, rather it is an aggregate entity. You can not create or update them directly. The only way you will get around this is to use the unbound action, msdyn_SaveCalendar.

To demonstrate this, I have created a simple Schedule entity. This is a child of Contact, with 2 datetime fields, start and end. The premise is the Resource, via a portal, will be allowed to add to their schedule by signing up for predefined slots, but this will mean that there is a schedule for each contact.

When a schedule record is created, we need to create the corresponding CalendarRule to show that this resource is available in the calendars used for planning.

Next, retrieve the calendar for this resource. The schedule is linked to a Contact, so use the Id to find the Bookable Resource.

Finally, call the action. It is in a loop as the List records always returns 1 or more records.

This is a JSON snippet, creating an object to add to the calendar.

CalendarId is the Resources calendar, ObjectTypeCode defines this as a Bookable resource, displayed here. TimeZoneCode is obvious, this points us to UTC. StartDate I have populated with the start of the schedule.

The next is a list of rules to add to this Calendar, you could create more than one here, but we don’t have to. Start and End time are taken directly from the Schedule record. Duration is the time in minutes for the scheduled appointment. This can be calculated by firstly converting both to ticks (seconds) and reconverting to minutes. I got this from an excellent response to a forum question here.

1

div(div(mul(sub(ticks(triggerOutputs()?['body/cc_end']),ticks(triggerOutputs()?['body/cc_start'])),100),1000000000),60)

Effort, timecode and subcode are required, defaulted to indicate a working period (timecode 0) and 100% effort (Effort 1).

Using Power Automate to generate Data

Tue, 02 Jun 2020 00:00:00 +0000

Previously, I have used Mockaroo and Flow to generate data, but the data I required for demoing the Customer Services Insights functionality has to be linked from existing data to be valid.

In this post, I will guide you through the methods I have used to randomise and create demonstration data that fits the requirements for Customer Service Insights, just using Power Automate and an Excel file.

TL;DR

Customer Service Insights only really works with data. This is great if you have some, but most demonstrations or trials have 10s of cases rather than 1000s. Here I walk through generating data using Flow, Rand() and Excel, mainly. Also, how to correct data if you didn’t quite get it the right first time 😊.

Creating Cases

Cases in D365 are linked to Contacts and Accounts and they need a title. As a bare minimum, this will create a case. But, for Customer Service Insights to work effectively, you need a few more parts.

Origin is where the case came from, typically Twitter, Facebook, Phone, Email, Web etc. This allows for the segmentation of your customer base by source. Products link the case back to the faulty product or service that the case was about. A Priority is also needed to define the workload case for your staff or denote a superior service. Also, we need to know the satisfaction or the originator of the case with the resolution. This can be taken from a Forms Pro survey, for example.

All these fields I have taken from the various parts of the Customer Service Insights reports and wanted to generate data with this populated to allow for an impressive and realistic visualisation in CSI.

But I wanted to randomise the data, it is quite easy in Flow to create records, but to randomise them you need to choose from a selection, you could query the data in your system for each of these, but I found it easier to use a central store of the lookup data.

Excel for Random Data

In Excel, I created an OneDrive file and added a table. In this table, I added several columns with information to build up a case.

Topic Start - Combine 3 fields to make the title of the case, which allows for randomising the title but keeping some keywords to allow for Topic categorisation by CSI.

IdCol - this is the key for the table. Each valid row has a unique number so I can retrieve the row in Flow later.

Topic Main - This is the middle part of the Title field. I am actually using a list of drug names I found on generatedata.com. By using a list, I hope to be able to drive the Topic categorisation.

Topic End - The final part of the topic, just some random words I thought sounded like ends of case titles.

Contact - This is the GUID for all the active contacts in the system. I exported the list to excel, unhide the columns on the left and grabbed that list.

Channel - These are the numeric values for the optionset used for Channel. I drilled into the options set from the field on the case.

Priority - Again a numeric values for the Priority optionset.

Product - This is a list of the active Product Ids in the environment.

Create Cases Flow

The overall flow is quite lengthy and has several conditions. Let’s step through it from the top. The flow is available in my CustServInsights solution here.

First of all, trigger the flow from a button. The input parameter denotes how many cases you would like to make. Ensure you keep this as 1 for testing. Also, initialise the case counter for use in the next loop.

Next, create a Do Until loop. This will keep looping until our case counter matches or exceeds the required number of cases.

Retrieve the random data

Next, get the relevant lines from that Excel file. For each of the fields, choose a random number from 1 and the maximum number for each data set and get the corresponding row in the Excel file. This is for Priority where I have 5 rows in the Excel sheet (I duplicate Normal which has a value 2 to weight the priorities in favour of Normal), hence the Rand function is

Rand(1_, 6_)

Rand (1,6) for Priority.

The Key Column is the IdCol of the file, populated with integers

This action is repeated for each of the random columns in the Excel file.

Create a case

Next, use these values to create a Case. Use the Create a new record action and populate with the appropriate values. Title uses a combination of each of the topic parts. Customer (Contacts) uses the confusing for citizen developers syntax to populate the contact on the case. This only applies if you are using the Current Environment version of the custom connector. There is an idea to revert this back to the previous syntax here. Please vote! I also added a description, just so I can retrieve these new cases later if I need to.

Origin uses the number for the optionset returned by the Excel and converts to an integer. The product field uses the same syntax as Contact.

Priority is converted to an integer as well. Record created on is used to alter the created date of the record. It is a pseudo change, as the record keeps both what you want to show and the actual date as separate fields in the CDS. Unfortunately, there is a bug in both CDS connectors and the D365 connector that strips out the time part of the field. I raised the bug here.

The compose used as a parameter is below. Use the rand function again to subtract up to 45 days from the current date and subtract up to 6 hours from the result. Finally, format the result to a date-time acceptable by the connector

Complete the SLAs

Once the record is created, randomise the closure as well as whether it met any SLAs in place for first-contact and closure. Firstly, generate another random number which will be used to define which path our case will take. Next, choose if this case is still open. Any value greater or equal to 8, so 8, 9 and 10 or 30% of the cases, should be still open.

On the positive side, the case is still open, another condition to decide if the case was responded to in time. This effectively means 10% of the cases will have failed their First response SLA and are still open. 20% will be still open but the first response was passed. The positive side of this condition is empty, the negative side, update the SLAs to show the first response SLA is met.

The first action in the negative side is a Update Record, using the Id of the created record. Update the first response field to Yes and the SLA succeeded to Yes. This is normally populated via workflow in the application.

The next step is to retrieve all the SLA instances associated with the record. These are created when a case is created (if you have a default SLA configured) and denote when the SLA for that case will be breached. To make these appear as if the case passed its first response SLA, update the first response instance for this case. Firstly, find the record. This is a list records action, against the SLA KPI Instances entity, with a filter to retrieve only those that are for the case created. The order by condition means that the first response instance is returned first, as it’s failure time is naturally before the closure SLA failure time. Using the top count of 1 restricts the return to only one record. This should hopefully mean we retrieve 1 record only and that is the first response SLA.

Loop through (there will only ever be one) the results and call an Update Record for each, marking the status as succeeded and populate the succeeded on date. Using the warning time will ensure it is prior to the failure time.

Closing the Case

On the negative side of the first condition statement, case is going to be closed, but first randomise whether this case met it’s case SLA. If the random number is 1 (10 % of cases) the case will be closed, but both the first response and case closure SLAs were not met.

In the Yes part, use the same technique to the get the case SLA instances and update all of them to Non compliant.

On the No side, make them all Succeeded and populate the date with the warning date, same as previous. The final part is to close the case. Whilst you now have the ability to perform an unbound action, I could not get it to work. Instead, I used a custom connector.

Custom Connector to close Incident

I have numerous posts about configuring custom connectors, start with this article on LUIS to create one. The action is CloseIncident and defined like this.

The body of the request is below.

1
2
3
4
5
6
7
8
9


{
 "IncidentResolution": {
 "subject":"test postman",
 "incidentid@odata.bind": "/incidents(7b978321-e7a0-ea11-a812-000d3a7fc8be)",
 "overriddencreatedon": "2020-05-22T13:28:43Z"
 },
 "Status":-1

}

This is a post action against the CloseIncident action, the request is defined below.

Drilling into the body parameter, you can see each of the parameters that are required.

Using this in Flow is straight forward, add a new custom connector and populate the parameters. Be careful over the case Id, as it needs the odata binding populated.

Finishing the loop

The final part we do is increment the counter variable to ensure only the number of cases we specified are created.

In terms of creating cases, that is it. I created nearly a thousand cases this way in 30 minutes (took a few hours to build out the code obviously) but this is reuseable and even 1000 records in 3 hours is not achievable by hand.

Updating cases Flow

There is always a time when you forget something. In this scenario, Customer Services uses the CSAT score and whether the case is escalated, and my original flow didn’t include that information. In hindsight, add these values to the Create case flow. To correct, I created another flow.

The trigger is the same, manual flow button. The first step is to retreive all the cases that I created. Remember I added to the description “This is a test case generated on UtcNow()”? This allows me to retrieve all the cases with a description that starts the same.

Then I loop through the retrieved cases. First of all, create 2 random numbers for use later. Then check if case is closed.

If a case is closed, all you can do is update the status and a few other fields, not all of them. If you try to update the Satisfaction on a closed case, you will get an error. So, for closed cases, open it first, by updating the record status and status reason.

Then, update the record for a second time, this time adding the Satisfaction and Is Escalated flag. Satisfaction uses a formula to state if the random number, 1-6 is 5 or 6, use 5 as the rating, otherwise use the value of the random number. This allows for a weighting of the satisfaction emphasising a higher rating.

Is escalated is true or false. In this scenario, I use a random again, so if the number is 5 or 6 using a range of 1-6, the case was escalated. This means only a small proportion is escalated.

Now the case has the data required, close the case again with the custom connector used earlier.

For the open case, side, just update the record, no need to open first.

Header Photo by Alexander Sinn on Unsplash

Mockaroo and Flow: Perfect Demo data

Thu, 21 May 2020 00:00:00 +0000

As a consultant, architect or just a blogger, you have to do a lot of demos. Recently, with my look at Sales Insights, the amount of data I needed was increasing. I had used Flow in the past to automate data entry, and it worked well, so I thought I would create some data for my environment using Flow, but first sourcing the data in Mockaroo.

Mockaroo

Mockaroo is a free data generator service which allows you to establish the fields you want and create a dummy import file for Dynamics. Great for my needs.

For Sales Insights Lead prediction, I need Leads. So, First and last name, email, account name, topic, job title and email. Mockaroo has various types which you can use to flesh out the data. Fake company names, random first and last name etc. It does a great job of ensuring the chosen name / last name also links to the email address. Some things I needed were not present, such as the topic. It doesn’t really matter for my demo what data was in there, just needed something random, which the type grocery products gives me.

Choose the number of rows you need, select the format as CSV and Download. Open in Excel to view your random data goodness.

Importing data into Dynamics has never been easier. Select Import from CSV from the Import from Excel menu on a view for the entity you want to import against (assuming you have enabled Import Data in security) and choose your file. Mockaroo uses double quotes for its quotation mark and comma as a separator. Select Review Mapping.

Here, map the CSV fields to the Dynamics fields, particular attention to the Primary fields which you need to populate. Hit Finish Import and this will queue your import job. Once successful, you will have a new set of “random” data for your use.

Augmenting your data in Flow

For Predictive Leads, you need 30 qualified and unqualified leads. To go through the steps to qualify each of the 1000 leads that were just added would be a time-consuming exercise. Also, there are some fields that the Predictive Leads default model would like, such as Industry type, budget, annual revenue and number of employees. These fields need updating with a random value prior to (dis)qualification.

Industry type is an option set. The Common Data Service connector at the moment doesn’t give the user the ability to retrieve the values so you have to resort to a Custom Connector.

I have been through customer connectors before, for my Org Settings app amongst others. A custom connector allows connection to the wider Power Platform API, where you can do all manner of things, but most importantly for us retrieve a list of options for a field.

Connector Action Definition

I am not going to go through the basics of the connector creation, see my previous posts for that. What is specific to this project is the action to retrieve the option set. The URL for retrieving a list of option set values is below.

1

https://{url}/api/data/v9.1/EntityDefinitions('{entity}')/Attributes('{field}')/Microsoft.Dynamics.CRM.PicklistAttributeMetadata/OptionSet?$select=Options

{url} is just the standard Power Platform log in url. {Entity} and {field} select which entity and field you want to return the values for. For example, to return the gender code options on Contact, you would use this url.

1

https://MYDEMOENVIRONMENT.crm11.dynamics.com/api/data/v9.1/EntityDefinitions('contact')/Attributes('gendercode')/Microsoft.Dynamics.CRM.PicklistAttributeMetadata/OptionSet?$select=Options

Transposing to the requirement for a custom connector, allowing for path parameters.

1

https://MYDEMOENVIRONMENT.crm11.dynamics.com/api/data/v9.1/EntityDefinitions('{entity}')/Attributes('{field}')/Microsoft.Dynamics.CRM.PicklistAttributeMetadata/OptionSet?$select=Options

The {} are placeholders for path parameters. Use this link in the Import Sample and choose Get as the verb should result in the below action configuration.

By editing the Query variable, you can make it default to Options, make it required and make it internal so it hides the value from your Flow call.

This should be enough for you to start with your Flow.

Update Leads Flow

This flow is manually triggered. First thing is to get the options set values, which is a call to the custom connector. I want the Industry Types, so use the entity lead and the field industrycode.

Next, get all the leads you want to update. In my scenario, all the leads created after yesterday which is still active. This is anything I imported.

Loop through the Leads and decide on whether it is going to be qualified or not. I do this by using the rand() function, which gives me a random integer between the first and second parameters. So, rand(1,4) would give me either 1, 2 or 3. As I want to favour qualified leads, only 1 counts as a lost deal. This will provide me with roughly 2/3 qualified leads.

Disqualification of a Lead

This is straight forward update record, but with a few interesting parts.

Firstly, using rand() again populated budget, employee and annual revenue. Use different min and max values to populate the values accordingly.

The only other interesting part is entering the Industry Type.

The expression is below and broken down to the key parts.

1

outputs('OptionSetValues')?['body/Options']?[rand(0, length(outputs('OptionSetValues')?['body/Options']))]?['Value']

Firstly get all the options return by my custom connector call.

1

outputs('OptionSetValues')?['body/Options']

Next, select one of the options by choosing a random number between 0 (o indexed array) and the number of options returned. If I have 10 options, the list will be returned with items in slots 0 - 9. So this effectively chooses which one I am going to use by random.

1

[rand(0, length(outputs('OptionSetValues')?['body/Options']))]

Finally, the Option is actually an object, the value I actually need to populated in the record is Value

1

?['Value']

I know, not exactly low code. There are other ways to do this, with Selects, etc., but this gives a one-line expression.

Finally in this lead update, set the status and status reason.

Qualifying a Lead

Qualification of a lead is a little trickier. Start with a lead update, which is the same as the one for disqualification except you don’t set the status/status reason.

Next, call the Perform an unbound action action. This is only available if you are within a solution and using the current environment connector.

Select an entity, Lead, an Action, QualiifyLead and Item Id, the record that has just been updated. I have selected Yes for all the create options, so it will create a Contact, Account and Opportunity as it processes.

At the bottom of the action, also update the status of the lead to 3, which is Qualified.

The problem with this action is that it causes an error, the return from this action is an object where it is expecting an object. I am sure someone more skilled in the way of Flow will be able to tell me the real way of fixing this, but for me, I just add a Compose action that does nothing and ensures this action gets called whether the Qualification fails or not.

The full flow is below. I manage to qualify or not 1000 leads in 27 minutes, admittedly it took a couple of hours to build the flow, but still, 2 1/2 hours for 1000 lead qualifications is pretty good!

Hopefully this has showed you some of the tools available to you via Flow to manipulate data.

Title Photo by Luca Abad Lopez on Unsplash

IFTTT - Stopping Freezer melt

Mon, 07 Oct 2019 00:00:00 +0000

I have a problem, well my family has a problem. We can’t shut the freezer door. Regularly (once a month) our freezer would be left open just enough to defrost but not enough to sound the audible alarm, resulting in squishy food.

Annoying.

To combat this, I bought myself a Sonoff TH10 temperature sensor and configured this to send me an alert when it reached a certain temperature. The problem is I became blase to the alert, as it would go off as soon as someone opened the door or was not around to react. The module would only alert me once, when a warm temperature was reached, not keep reminding me or escalate to someone else when I didnt react by shouting at a teenager to close the door. So how could I ensure it alerted me less frequently and also alert the rest of the family when there was a real issue?

I know that this article is a little bit of fun with no real business benefit, but using Flow to fix a problem in my life is worth talking about. Everyone will have a little annoyance that Flow can help with, and it acts as a training exercise for us all.

Design

As with all problems, starting with a flow chart helps. This is what I need to achieve. The Sonoff device is configured to turn on and off when a certain temperature is hit. IFTTT is triggered by Sonoff on both of these conditions.

When the hot temperature is hit, wait 30 minutes (to allow for the temp change when a door is opened and closed naturally) then check if freezer is still is over temperature. If it is still hot, send out a notification.

Then, wait 60 minutes now and check again if the temperature is too high, before repeating the loop, sending out a further notification and waiting 60 more minutes.

If we check the temperature and it is now back down to cold, stop the process.

IFTTT configuration

If you don’t know the IF This Then That, it is a great service to interact with disparate systems, a point-to-point integration to do something on a trigger. I have used it previously to log Sales users calls from an android phone and I use it to change my phone’s background with the NASA wallpaper of the day. It is a free service which plugs the gaps where Flow does not have direct connections, such as with the Sonoff device.

Sonoff can trigger IFTTT, which in turn can trigger a web service, triggering the Flow.

Log into IFTTT and link your account to eWeLink (this is the app you install to manage the Sonoff switches).

Select Create from your account

This presents you with the standard IFTTT applet creator.

Hit the big + to display all the available services, eWeLink should be on that list.

Next, you get a long list of the options eWeLink make available for you, this is where you need to select the appropriate switch, for me just a single channel switch.

Next step is to select your switch, named by you when you configure it in the eWeLink app, and whether you want this to be triggered when it is switched On or Off. For me, On means that the Freezer has gone below -20 ° C. Off means it has gone above -17 ° C.

IFTTT then needs to know what to do.

Hitting the big + again lists the action services, the one we want is a WebHook.

Next, the action requires a URL, which is from our Flow, so skip to that bit to get the URL, we aren’t posting anything to this hook, just a trigger. You could secure this a little more to pass in a key to know it is you that is triggering it.

Flow Configuration

Our flow starts with a web trigger.

I am passing a delay to the trigger, though the initial call will not have any delay.

Next, initialise a variable for checking the freezer later as well as an ID for the SharePoint Item I will create later.

If this has come from the initial IFTTT trigger, then we assume the delay is 30 minutes. You could just update a delay variable, but as you will see, I want to do something different if I am passed a delay, the second time we call it.

In the yes branch, we now wait for the default 30 minutes.

Cancelling the Flow

Now, according to our design, we need to check the temperature to see if it has dropped back below our trigger point.

Ideally, you would call the Sonoff and ask for a reading, and I am sure more expensive IoT devices allow you to do this, but I am cheap. The Sonoff and eWeLink interfaces allow you to look at the temperature on your phone, but do not broadcast the temperature out to anyone apart from the App, just the on / off trigger. Checking the temperature is not an option.

What about creating another trigger to turn off this looping? Unfortunately, this isn’t possible; there is an idea on the flow community; you can vote for here. I would also like to be proven wrong, reach out if there is a way to cancel a flow run.

I started doing this by adding a file in a Google drive location (it could be SharePoint or OneDrive but wanted to expand my use of connectors) when the temperature went down, but this was inconsistent. I ended up getting multiple emails as the file create did not happen every time. I am sure I could sort this out, but wasn’t really the point of the flow.

I ended up with creating an item in a SharePoint List when the flow was first triggered, complete the delay and check this item to see if another process has updated the same item while I was in pause mode. If that item has been updated, just stop the Flow. If it hadn’t send the email alert and trigger the flow again, to repeat the process.

First, create the item in SharePoint, with the current time (this is just for my interest, knowing how many times it triggers the freezer temp)

The Id of the item that is created is copied so we can pass it to the next iteration of the flow if needed.

After the delay, check the item that was created for a cold temperature. Using a bit of odata filtering here to only return the item that was just created and only if there is no cold time.

This Scope useage is only to allow me to copy the contents to the other branch, saving me time. The copy function is really useful, if you havent seen it, why not?

Next, if any items are returned (the item that was created was updated with a cold temperature), the title is changed to Cancelled. This is not really needed, but gave me something to do in the apply for each. The boolean is set to true, meaning Freezer is now cold and this flow can cancel itself.

Out of the loop, check the value. If the previous loop did anything, it will be true, if not false. If the freezer is now cold, just terminate gracefully. If it has not updated the temperature, let it fall through to the next action.

The final part of the original check to see if it sent a delay count is to email. In this no delay sent path, an email is just sent to me. I am using Gmail here, just because it was a new connector.

Finally, call the same flow but pass in the delay we want and the Id of the SharePoint item that was created.

What about if it gets really serious?

Telling me if the freezer has been open is fine, it usually results in a yell to a teenager to shut the f**king door. What about if I am not in?

After the first 1/2 hour delay, if the freezer is still showing hot, I need to escalate, for me means emailing my whole family. In the No branch, I delay for whatever value was sent in, set a variable to pass on to the next iteration and do the same code as in the other branch, the difference is that I include more people on the next email.

Here, I email all my family, with a nice in your face subject and also hike up the importance. Hopefully, they won’t ignore this email like they ignore me.

Triggering when it is cold

Using IFTTT the same as I have done early on, if the temperature hits -20 ° C, the second trigger is fired. This updates any items it finds in the list without a cold temperature with the trigger time

And that’s it.

In my inbox, after I have taken the temperature controller out of the freezer for a little while, I get a series of Freezer is hot messages, also sent to the rest of the family.

Once it gets back in, the notifications stop.

And in SharePoint, there is a list of the hot & cold triggers, from natural door opening, thankfully

Cloning Flows: Location triggers for everyone

Sat, 14 Sep 2019 00:00:00 +0000

Sometimes ideas don’t work out. This is one of these times. But the reason I blog is to learn, expand my knowledge of the PowerPlatform, expand my knowledge of components outside of it. So, I figured I would blog about my failure, learning is learning. As I started testing the flow again, moving environments etc, it started working. I guess this is down to the location trigger being a work in progress. Moral of the story: If it is broke last month, try again this month.

Back in July, I started working on this scenario, but couldn’t get it working. I noticed @Flow_Joe_ & @JonJLevesque did a video walkthrough of using the Geofence trigger to send out a summary of the customer when a sales person enters an area, which reminded me of my failure, hence why I have written it up. While from Joe & Jon’s video shows us how easy it is to create a flow, for Salespeople in general, I think this is too far. You can not expect a Salesperson to have any interest in creating flows to do this, you can expect them to click a button on a form within their D365 application.

Objectives

The Scenario
Creating the Flow button
Cloning the Flow
Outcome

The Scenario

Numerous times when I have been a customer, a salesperson would come to us not knowing that we have several major cases logged with them against their product. This is mainly down to lazy sales people (I know, they don’t exist), but it would be awesome for the salesperson to get a summary of the account when they get in the door of a customer. The number of support cases, a list of the open opportunities and orders, any complaints that have been logged. All of this information is available to the salesperson via the D365 mobile app, but it would be good to ensure that they get this information and are less likely to get caught out by a customer venting at them for 5 critical bugs that have been sat around for a month.

The Solution

Flow has a new trigger, still in preview, Location, which is triggered via the Flow application when an user enters or exists an area. This is perfect for our scenario, stick a GeoFence around a customers location, when the user enters the area, it gets triggered. Look up the Customer, format an email and send it to the user.

Flow is user friendly, a low code solution, but you can not expect a salesperson to create a flow for each account they want to create this trigger for. What can be done, is put a button on a form, automatically create a Flow for the user against the account they have selected which would then be triggered when the user enters the location.

There are 2 separate series of flows that are required, firstly to start with an action from the user on the account record, which triggers cloning of a template.

The second series is the clone of the template, which triggers sending the salesperson the relevant information when they enter the customers property.

Creating a Flow Button

Starting with a CDS “When a record is selected” trigger, configure it to be used when an account is selected.

The next step is to retrieve who is running this flow. As mentioned, it will publish this button on a Account form, so it is essential to know who is running this, so an email can be sent to them. The account information and who the user is is sent as the body to a HTTP Post trigger, which is the next flow in the chain.

An HTTP trigger is used because the next Flow requires enhanced access. An admin user needs to clone a Flow, which you would not want a normal user to be able to do. The admin is used as well to ensure any runs that happen are legitimate. The admin or sys account shouldn’t belong to someone who could have Flow in their pocket.

To have the URL to send to, the next Flow needs to be created first, but just to show where this button appears within the D365 interface. The first time we run it, there are few confirmations that you need to do, finally you can run the flow.

Cloning the Flow

This flow clones an existing template, tweak it slightly and gets it up and running as the user.

Starting with an HTTP Trigger, I use a sample payload to build the schema.

Next is retrieving the account. As the account id is passed in from the calling Flow, a simple Get Record is used.

Next, configure the name of the Flow that will be created, making it unique for the user by adding their email address in. A flow definition string is also initialised for later

In this Flow, the user that called it from the button is needed, so it retrieves the profile using the Office 365 Users action.

Next, retrieve my template flow. Flow has several actions around management of Flows, which are incredibly useful to a Flow administrator. The template flow is a simple flow which has a location trigger and a call to a http trigger to call a secondary flow. I will discuss later the detail about this.

The next couple of actions try to determine if a flow with the FlowName defined already exists, firstly by getting a list of all my flows (as an admin) then getting a list of Flows in the organisation, then filtering it with the flowname that was defined in the initial steps

If there is a flow already, just stop. If not, carry on & clone the template flow.

The Template

The Log Template is a very easy, small location trigger with an HTTP call action. The HTTP call passes in the user’s location and the account id and the user who started the process. Both email and account will be swapped out as part of the clone.

The trigger region is essential for any location trigger. It triggers this one of the Microsoft campus in Redmond. Someday I will be fortunate to go to the motherland. I chose this as it is not likely that the user would have them as a client, but it doesn’t really matter where you chose, as what you need is the latitude and longitude from it so you can replace it when you clone the flow.

If you click on the peek code button against the trigger, it shows a JSON representation of the trigger. The latitude and longitude are that of the Microsoft office and this is the bit I need to replace

Cloning the Flow (part 2)

All a Flow is a JSON file. Obviously, how it is rendered and how the hooks and actions work are the power, but the definition is a JSON file. Using this knowledge, we can create a new version of the template, with a location specific to the account.

The template in all it’s glory is below. Just using simple find / replace, we tweak it to the specific location, account and user.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


{
 "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "$authentication": {
 "defaultValue": {},
 "type": "SecureObject"
 }
 },
 "triggers": {
 "manual": {
 "type": "Request",
 "kind": "Geofence",
 "inputs": {
 "parameters": {
 "serializedGeofence": {
 "type": "Circle",
 "latitude": 47.64343469631714,
 "longitude": -122.14205669389771,
 "radius": 35
 }
 }
 }
 }
 },
 "actions": {
 "HTTP": {
 "runAfter": {
 "Initialize\_Email\_Variable": \[
 "Succeeded"
 \]
 },
 "type": "Http",
 "inputs": {
 "method": "POST",
 "uri": "https://prod-68.westeurope.logic.azure.com:443/workflows/<GUID>/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=<SIG>-JQQvYT0",
 "body": {
 "lat": "@{triggerBody()?\['currentLatitude'\]}",
 "long": "@{triggerBody()?\['currentLongitude'\]}",
 "user": "@{variables('Email')}",
 "account": "@{variables('accountId')}"
 }
 }
 },
 "Initialize\_Account\_Variable": {
 "runAfter": {},
 "type": "InitializeVariable",
 "inputs": {
 "variables": \[
 {
 "name": "accountId",
 "type": "String",
 "value": "<accountId>"
 }
 \]
 }
 },
 "Initialize\_Email\_Variable": {
 "runAfter": {
 "Initialize\_Account\_Variable": \[
 "Succeeded"
 \]
 },
 "type": "InitializeVariable",
 "inputs": {
 "variables": \[
 {
 "name": "Email",
 "type": "String",
 "value": "<email>"
 }
 \]
 }
 }
 },
 "outputs": {}
}

Back on the clone flow, the next step is to convert the template to a string. This makes it easier to replace the latitude, longitude etc. with the ones we want.

On the account OOTB record there is a latitude and longitude. This data is not normally populated, but it is used by Field Service and other applications. I used Field Service to populate it using the Geo Code button.

As you can see from the above, Field service populates both latitude and longitude to 5 decimal places. This is common precision when you use any mapping software such as Google. so I am not sure why if you do the same by the Flow trigger you get precision to 15 dp for latitude and 17 for longitude.

The next 2 steps are because of me trying to get the flow to work. One of my thoughts was that the flow was expecting the all 15 of the decimal places to be populated, so these steps pad out the number you have against the account with additional numbers.

The expression is the same for both

1

concat(string(body('Get\_Account')?\['address1\_latitude'\]),'111111')

The next step replaces the newly calculated values for latitude and longitude in the JSON definition

1

replace(replace( variables('flowdefstring'),'47.643434696317136',outputs('Replace\_Lat')),'-122.14205669389771',outputs('Replace\_Long'))

The accountid is also replaced. This is used in the cloned flow to define which account the user selected. The trigger only gives you the user’s current location, not the centre of the circle you configured. You could use these values & find the account, with difficulty, unless there is something I am missing. I prefer to add a variable in the clone, which is the account id.

1

replace(outputs('Replace\_Lat\_Long'),'<accountId>',triggerBody()?\['Account'\])

The same with the email to send to, it should be the user who triggers the geofence, but seems to be the person who is the admin. As I clone the Flow with an admin account then add the user as an admin, it runs under the admin account.

There is enough info now to create this flow. Using the Create Flow action, the new flow is created and up and running.

I use a JSON expression to convert the string I have used to find / replace the latitude, longitude etc. to ensure the Flow is created with JSON.

1

json(variables('flowdefstring'))

The final step is to add a Flow owner. As the sales person who triggered the flow is who it should trigger on, make them the owner, so it should run under their context.

Outcome V1

Ignore this bit if you want to avoid the author moaning about stuff that doesn’t work.

If I run the whole flow, I do generate a new Flow.

Going into what was generated, using peek code again, you can see that the Microsoft location has been replaced with the Avanade office

The trigger is active, but this is where it stops. I can not get this to trigger to fire. Changing the location to my home, going for a walk, coming back doesn’t trigger it.

If I don’t put in the padding for the latitude and longitude, it doesnt trigger.

If I clone from my location, not changing the latitude and longitude, still the trigger doesn’t fire.

If I configure a new trigger from scratch, that works.

Everything about the trigger look the same when you get it in code view, but there must be something different.

This is where I started reaching out, I tweeted about it to the gods of flow and asked in the Flow forum where I did get a response, basically saying the same, and that the location trigger is in preview.

So, if you have got this far, how do I fix it?

Outcome V2

Like I said at the outset, this didn’t work for me. Frustration set in, and I forgot the idea. But, as I was putting together this blog post, re-deploying the components as my demo system had expired, it worked!

So, moving on, we need to sent an email to the user with the playbook for the account. I want to list the last 5 critical cases, last 5 open opportunities, last 5 notes and any description the user has put in.

It triggers an HTTP request, the schema defined by a sample payload, but contains who triggered the workflow and which account.

Then, a great time for a parallel branch. The Flow retrieves the cases, notes and opportunities in a parallel branch.

Each branch does a similar thing, looking at the Notes branch, firstly retrieve the records with a CDS List Records action, using an OData filter and order by, return the top 5 only.

Next, put this in an HTML table, selecting the output from the Get Notes action. I select Advanced option, then Custom columns, this way I can define the order and which columns I want to display.

The final step is to send an email

Obviously, this can be customised to your business need, but my example list the cases, opportunities & notes, and reminds them to fill in a contact report.

Summary

So, the user selects a button on an account form, which allows them to receive updates about one of their customers when they enter the location of the account. Easy.

I tested this with my home address and with a different user and you can see that I get the email through. Veronica is in the US, I wasn’t up at 1am writing blogs & fixing Flows.

You can also see that Flow notifies the user that it has made them an administrator on a Flow.

This Flow starts with a Flow button on a record, making it a user-initiated process. It could be triggered off a record creation process - If the user follows an Account, create this automation for them, as long as they have opted in.

There is location tracking in the Field Service application, but that requires the Field Service mobile app and not suited to a Sales person. They just need to install the Flow app on their device and forget it is there.

AI Builder - Text AI

Thu, 05 Sep 2019 00:00:00 +0000

My blogging journey started with using LUIS, one of Microsoft’s Cognitive Services to automate case assignment. This blog goes into detail about how this all hung together, using a model defined in LUIS, calling the LUIS endpoint when a new cases are created and classifying the case, by the subject, with the result from the call.

After my summer break (sorry, but family etc comes first) I thought I would revisit this scenario, but using one of Microsoft’s shiny, new AI Builder capabilities, Text Classification AI Model.

Objectives

The Scenario
Training your Model
Getting Data
Publishing the Model
Using the Tags

The Scenario

In my first blog, I went through the scenario, so not wanting to repeat myself, but for the lazy who don’t want to click through…..

Big Energy is a supplier of energy products to end users. They have a call centre which handles any query form the customer. As a perceived leader in the sector, it is always wiling to use the latest technology to allow users to interact with them, which reduces the pressure on the customer support centre.

Big Energy has a mail box configured to accept customer emails about anything and, rather than have a group of 1st line support employees filtering out and categorising the emails based on the content, want to use cognitive services to improve the process of getting the email (the generated case) to the right team.

Using AI to file the case

LUIS does a great job of this, with a BA providing sample utterances for the model and training it.

Text Classification AI Model does it slightly differently. The model expects users to provide data (in the CDS) in the form of text blocks and representative tags for the data. Both need to be in the same entity in CDS.

On a standard Case record, the classification or tag is the subject field. This is a parent record of Case and the tag would be the name of the subject. As subject and case are separate entities, the Text Classification AI model will not work. A field, be it a calculated one, has to be introduced to enable the classification AI to work. Adding data to an entity from a parent entity breaks my Third Normal Form training (anyone remember that? Is it still a thing?).

I have raised this issue as a new idea on the PowerApps ideas forum, go there and give it a vote!

The new logic for our AI model is that the AI will classify the incoming case, adding a tag. This will trigger a flow, changing the subject of the linked case accordingly. This will trigger re-routing of the case like it did in the original LUIS method.

Training your AI

With any AI model, it needs training. The AI needs to separate the wheat from the chaff. Creating a model is simple in PowerApps.

Start at make.powerapps.com and select AI Builder, then Build

There are 4 options here

Binary Classification is useful to give a yes / no decision on whether data meets certain criteria. The criteria can be up to 55 fields on the same entity. For example, is a lead with a low current credit limit, high current account value, no kids but has a pink toe nail (shout out to Mark Christie) likely to get approved for a new loan?

Form processing is intended to assist users in automated scanned documents to prevent re-keying. An example would be any forms hand written as part of a sales or service process (before you convert to a PowerApp obviously).

Object detection assists in classification of items, be in types of drink, crisps or bikes, etc.

Text classification decides on a tag for a block of text, for example, a user could enter a review of a product online and text classification could understand what product it was for or whether it is a positive review.

All 4 of these have origins in the Cognitive services provided by Azure, LUIS being the big brother of Text Classification.

Ensure you are in the correct environment. Text Classification only works on data within your CDS environment, so don’t expect to reach out to your on-premise SQL server. There are ways to bring data into CDS, not in scope for this discussion.

Selecting Text Classification displays a form to give you more understanding, and it is here that you name your model

Hit Create and then Select Text. This will list all your entities in your CDS environment (in my case, a D365 demo environment).

Select the entity you want, Case for our PoC.

The interface will then list all the fields suitable for the AI model, namely anything that is a text field. I chose the description field, which is typically the email that the user enters when emailing in a case to the support department.

Hit the Select Field button and it will present you with a preview of the data in that table.

The next screen is to select your tags. This needs to be in the same table, and as already discussed, is a bit of a limitation to the AI builder. Less normalised data is more common in Canvas apps or SharePoint linked apps, but for structured data environments with relationships and normalised data this is a limitation that will hopefully be removed as Text Classification matures.

Also, option sets are not available, again another common categorisation technique. Multi-select option sets are an ideal tagging method too. Assume that this will come in time.

For my PoC, I created a new field, put it on the Case form and started filling it in for a few records.

Select the separator. If your tag field contains multiple tags, separated by a comma or semi-colon, this is where you configure it.

It also gives you a preview of what the tags the AI build would find using your chosen method. You can see in the No separator option, “printer; 3d” is one tag, rather than the assume 2 tags as displayed if semi-colon is selected. This depends on your data.

The next page displays a review for your data and the tags that the AI builder finds.

Next, select a language for the text field dependent on your data.

Once selected, train your model. This is where I started to run into problems. My initial population of tags was not enough. The training came back quickly with an error. There should be a minimum of 10 texts per tag, which I didn’t have. That would be hundreds of rows. How was I going to automate creating data to give the Text AI enough data to be a suitable demo?

Getting Data

I need thousands of records to train my model properly, thousands of records relevant to the tags I create. No online data creator seemed suitable, as it wasn’t specific enough, so how? A flow.

First I created a column in the Contact table to store a number for my contact, a unique no so I can randomise the selection of a contact.

Next, I need some data for the case description and the tags. This is already done as it is the same as the utterances and intents I used for LUIS, so I exported the LUIS configuration, put the data in an excel file & added a number to that.

Ready for the Flow

My simple flow is described below.

Ask for the number of cases to create, keep creating cases until you have reached that limit using a random contact and a random description.

This flow is triggered manually so I start with a manual trigger and also prompt for the number of cases to create,

The Subject variable is used later to define the reference for the subject we have chosen.

The default for loops is 60. I realised late on in the day that you can change that, but breaking up loops is good practice, to limit the scope of what could go wrong, so created a loop within a loop structure for my flow.

I restrict the inner loop to 50 loops maximum, which means the number of times I run this loop has to be calculated. If I want a 920 cases created, my outer loop would occur 45 times, each creating 50 cases. I would then do a final set for the rest.

The next steps will initialise some counters used in the loops. I also want to ensure that if the user wants to create less than 50 records, the outer loop doesn’t run at all.

The outer loop will run for the number of loops I have calculated. This is the loop condition. The counter increments as the last thing in the outer loop. The first thing in my outer loop is to reset the case counter. This is the counter for the 0-50. If we are in this inner loop, at least 50 cases will be created.

The first thing it does is get a random contact by using a odata filter to filter on the number field created specifically using a random number from 0-875 (875 being the highest number in that table).

Once the contact is retrieved, find a random description / tag combination. The data from the LUIS utterances is held in an Excel file on a Teams site. Again, a rand() function takes a random number up to the maximum in that file.

Because more than one subject row could be returned and the fact I don’t like apply to each inside each other, set the subject Id variable.

Ready to create a case now.

Nothing special. It also populates the tag field.

After some testing, to ensure that the case has the necessary fields entered, the flow was run for a thousand records without an issue.

Creating data this way isn’t quick, 20 mins for 1000 records, but it is easy and allows you to bring in reference data quickly. Superb for PoC environments.

Training your Model (with data)

Once this data is generated, it was time to re-train my model. It ran through with success this time.

The model is 97% sure that whatever I throw at it, it should be able to match it against the tags. There is a quick test option here too, which allows entry of a sample phrase to check your model

All ready to publish.

Publishing your Model

Publishing the model allows it be used within Flow and PowerApps.

Clicking Publish generates a child table of the entity you first chose where the predictions are stored. The documentation states the table will be TC_{model_name} but it created mine with gobbledegook.

The link on the form helpfully allows you to go straight to the entity in the new customisation interface, where you can change the label of the entity.

Also, it is useful to change some of the views, particularly the associated results view. By default it includes name & date, which is pretty useless, so add the tag and the probability.

As this is a child table of Case, it is by default visible in the case form Related navigation item. In the classic customisation interface, you can change the label of this view.

As it is published, users can use flow and the Predict action to predict the tag for a given section of text, useful if you want to do stuff before it reaches an environment.

Now that it is published, you need to allow the model to run. This means it runs every time there is a change to the text field. This is all done via Flow, so will use your flow runs. It stores the result in the new entity.

If a case is created now, it automatically creates the tag secondary record.

Using the tags

As AI builder generates a record for you with its prediction, and the data is in CDS, it is a simple Flow to utilise that. As it creates a record in the AI Tags table, update the corresponding case to change the subject accordingly.

Simple trigger when a record is created. The first action is to find the subject from the tag.

Update the case record with the subject and the tag so the AI can be retrained later.

That’s it. Replacing LUIS with a more user friendly environment is definitely a tick in the box for Microsoft. The AI in PowerApps feels like a simple, user friendly stepping stone for a lot of businesses into the AI world. Hopefully, businesses will embrace these simple models to leverage tools to shortcut processes, improving Employee and customer experiences.

Adaptive Cards - Improved Approvals (Part 2)

Fri, 05 Jul 2019 00:00:00 +0000

Continuing on a walkthrough of creating a more effective adaptive card for approvals, this part will describe the flow I created to generate the card as well as complete the action in D365 depending on the response

Objectives

The Scenario (Part 1)
Preventing progress of an Opportunity ( Part 1 )
Using Flow to create a basic Approval ( Part 1 )
Creating an Adaptive Card ( Part 1 )
Using Flow to create the Approval (This Part)
Updating the Opportunity (This Part)

Starting out

As previously described, the Flow is triggered when a user updates the Develop Propsal checkbox. In the first stages, the flow also retrieves some records that are needed later on for population of the card. There are also initialisations of 2 arrays that are used to populate the approvers and product lines on the card.

The next section is used to retrieve the approvers for the territory. In part 1, a many to many relationship was added, linking User to Territory via the territory approvers table.

As the territory approvers table is a many to many relationship, it does not appear as a standard table in the common data service connector, nor the D365 connector. There are various blog posts out there which state you can just use a custom value, naming the table, but I couldn’t get it working, so I fell back to my custom connector.

In my previous post on Security roles via a PowerApp, the custom connector which allows an FetchXML string to be sent against an object is used a lot to get the teams and the roles for a user. This connector is again used to find the users associated with a territory via the new relationship. The FetchXML is below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<fetch top='50' >
 <entity name='systemuser' >
 <attribute name='internalemailaddress' />
 <attribute name='fullname' />
 <link-entity name='cc\_territory\_approver' from='systemuserid' to='systemuserid' intersect='true' >
 <filter>
 <condition attribute='territoryid' operator='eq' value='@{body('Get\_Account\_Manager')?\['\_territoryid\_value'\]}' />
 </filter>
 </link-entity>
 </entity>
</fetch>

This will return JSON which corresponds to the users linked as approvers to the territory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


\[
 {
 "@odata.etag": "W/\\"3421832\\"",
 "internalemailaddress": "veronicaq@CRM568082.OnMicrosoft.com",
 "fullname": "Veronica Quek",
 "systemuserid": "824da0b2-6c88-e911-a83e-000d3a323d10",
 "ownerid": "824da0b2-6c88-e911-a83e-000d3a323d10"
 },
 {
 "@odata.etag": "W/\\"1742271\\"",
 "internalemailaddress": "danj@CRM568082.OnMicrosoft.com",
 "fullname": "Dan Jump",
 "systemuserid": "e3b305bf-6c88-e911-a83e-000d3a323d10",
 "ownerid": "e3b305bf-6c88-e911-a83e-000d3a323d10"
 },
 {
 "@odata.etag": "W/\\"3422353\\"",
 "internalemailaddress": "CarlC@CRM568082.onmicrosoft.com",
 "fullname": "Carl Cookson",
 "systemuserid": "113f1e3a-db90-e911-a822-000d3a34e879",
 "ownerid": "113f1e3a-db90-e911-a822-000d3a34e879"
 }
\]

An approval needs a list of email addresses, separated with a ; . To achieve this, firstly put each of the returned email addresses in an array, then use the Join function to create the string used for approvers

Populated the Main approval

The next part the body of the approval that is going to be sent. I’ll link the full version of this at the end of the article, but effectively, you copy your design, remembering to insert appropriate dynamic content on the way.

Here, I create the 2 URLs that are displayed in the card, which combine the starting point of url and append Account or Opportunity Id.

This is displayed at the top of the card.

Further, formatting currencies is difficult in Flow. (I stand to be corrected). I found this post on Power Platform community which highlights the issue and degvalentine has the solution, which I have tweaked to take into account of null values in the fields in D365. This example is for one of the fields on the secondary grid.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


if(empty(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\])), '0',
concat(
 if(
 greaterOrEquals(
 items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\],
 1000
 ),
 concat(
 substring(
 string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]),
 0,
 max(0, sub(length(first(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.'))), 3))
 ),
 ',',
 substring(
 first(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.')),
 max(0, sub(length(first(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.'))), 3)),
 min(3, length(first(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.'))))
 )
 ),
 first(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.'))
 ),
 '.',
 if(
 contains(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.'),
 concat(
 last(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.')),
 if(
 less(length(last(split(string(items('Add\_to\_Prod\_LInes')?\['manualdiscountamount'\]), '.'))), 2),
 '0',
 ''
 )
 ),
 '00'
 )
)
)

Populating Product details

As the approval body is built up, the next stage is to create a table with the product lines in it. Getting the lines is a simple filter query using the primary key on Opportunity.

Like with the approvers, an array is populated with a formatted version of each line, taking fields returned and combining them with formatting rules.

The first expression deals with the fact one of the products chosen to demo had a double quote (") in it, which messes up JSON if it isn’t escaped as it is the string delimiter. I used a simple replace expression to add a “\” before it.

1

replace(items('Add\_to\_Prod\_LInes')?\['productname'\], '"','\\"')

The next expression is the one above to format the currency with the appropriate commas and decimal places.

The output of this looping of the product lines is then combined using a join again, then combined with the body main string.

The bottom of this string starts the list of actions, which are the buttons.

The next step is to create the Approval. This is pretty simple, using a first to respond type, and fleshing it out a bit, so if a user uses the standard Flow Approval interface, they have something to relate to. No notification is needed, this will send an email to the approver, but the Flow will alert the approver via Teams.

My original design for this PoC was to push this notification / approval to a Team channel, one notice to the Approvers channel. As Teams integrates with D365, it did not seem much of a hop to highlight the Opportunity approval.

The only issue is that approvals don’t work in team channels, only when sent to a user. Until this is resolved by MS, you are limited to sending the approval to an individual in Teams.

Sending the Approval

The key bits of this action is ensuring you have the Approvers tenant (can you post approvals across tenants?), the respond link, the approval ID and the creation time populated with the data coming from the approval. The same goes for the Reject action.

That’s it, the new approval is sent.

Waiting for the Approval

As the approval is configured that anyone could approve or reject, the next action is to wait for that approval to happen. Approvals can happen upto 30 days, which is another issue, but as this is to speed up the approval process, let’s not worry about that.

If the outcome is approved, then the field Complete Internal Review is checked and a note is created, linked to the Opportunity logging who approved it.

This is in a loop, as, in theory, there could be more than one approver on an approval, if you use the Approval setting that forces everyone to approve something.

The Regarding / Regarding type, highlighted above, need to be populated as you get orphan records and can spend 20 minutes wondering what is wrong (not me obviously)

On the Reject side of the condition, the Opportunity is put back to the state it was in before the flow started, namely Develop Proposal is reset. This triggers our Flow again, but as long as the first condition is met, it won’t go any further. A note is also added, to highlight who rejected it and why.

Adaptive Cards - Improved Approvals (Part 1)

Thu, 04 Jul 2019 00:00:00 +0000

Adaptive cards are relatively new to the stack of tools available to PowerPlatform users, emerging from Message Cards. They are a great way of interacting with users who are not a typical D365 user, those on the periphery who are interested in the data but not the detail.

Objectives

The Scenario (This Part)
Preventing progress of an Opportunity (This Part)
Using Flow to create a basic Approval (This Part)
Creating an Adaptive Card (This Part)
Using Flow to create the Approval
Updating the Opportunity

The Scenario

Big Energy is going well, they are now involved in some big deals for big enterprises which need a lot of time to land. The proposals that are generated are complicated, and they struggled with some dubious sales people reducing the margins just to get the deals and this is just bad for business.

An approval process needs to be implemented, where one or more of a designated group of individuals per territory review the opportunity and decide if the margins are appropriate.

Unfortunately, the approvers tend to be very busy senior directors, who use D365 sporadically, if at all, and Big Energy need to allow them to approve the opportunities where ever they are using Outlook or Teams as the preferred option.

Tweaking the standard Sales process

Microsoft provides a Business Process Flow for Opportunity management, and in our scenario, only the approvers should be able to check the boolean Complete Internal Review. This is part of the standard Propose stage of the BPF.

To “lock” (I know it isn’t foolproof, what is?) the progress on Propose, the Complete Internal Review is subject to a simple business rule, if the opportunity is at any stage, lock the field.

Now, no one can edit that field, if that field is made mandatory to progress the bpf stage, no one can progress the stage past propose.

Territories are often used in Sales to group accounts or account managers and in our scenario, there is a set list of approvers for a territory. I have added a new many - to - many relationship for this, Approvers and ensured it is listed in the user form as one of the relationships

Using Flow to create an Approval

In the standard Propose stage, there is another boolean that is of interest, Develop Proposal. The Flow is triggered when this value is changed. A simple CDS update trigger is the starting point.

The next stage is to confirm that this trigger is coming with the correct record state, the record has been marked with Develop Proposal, but the other field, Complete Internal Review is still empty.

The flow to create the adapted card is fairly intense, well, from my experience, as you will see, so for now, create an Approval using enough details to get the default experience that can be built on.

In Details, there is a lot you can do, using markdown but this is not as comprehensive as the formating you get from adaptive cards.

When this flow is run, you will get an email to the assigned to with a simple, standard approval, which is in itself, an adaptive card, but it is fairly plain.

Using the Flow history, this action also shows the adaptive card that was built

Copying this value into the Adaptive card designer JSON section gives the format for a basic design, which can be augmented to show some proper information

Building an Adaptive card

Adaptive Cards are a means to interact with your users via email, teams or any other app that handles the rendering of them. They have actions, allow images to be presented and can format text in a markup that imitates a comprehensive website. They are supported in Outlook mobile apps as well as O365, either using the main app or online.

They work by rendering a JSON object, which can be formatted to match the host application (the dark black Teams theme for example renders it very differently, but the core actions are still there.

Microsoft has built a superb tool to manage Adaptive cards, the new version, at adaptivecards.io/designer. This site has lots of examples to get you started, the Expense Report is a good starting point from a design point of view, but the standard approval card forms the base for the card. There are bits in it that you need to incorporate into your card to allow the approval to work.

The parts in the data section are the essential bits that, in our adopted JSON need to be duplicated or populated by Flow to allow our card to act as an approval.

My card is a bit different than the standard, displaying key parts of the Opportunity and the associated product lines.

As you can see, there is a lot more information on what is happening on the opportunity, probably enough for a sales manager to make a decision in most cases. Included in the card are links to the Account and Opportunity if further review is needed.

I would recommend starting from a sample and building your content, with dummy data, so you can get the layout correct.

Each of the buttons are also cards on their own, allowing a comment to be made before the approval is approved or rejected.

These have been copied from the standard adaptive card produced by the Flow approval so that the submitted approval works like a standard approval.

Some considerations and limitations

I first started trying to reproduce the Expense Approval card in full from the samples

This has a great use of hidden / visible sections of the expense lines which could give you a lot of real estate for Opportunity lines. Unfortunately, these are not rendered in Teams.

Also, I thought I would be able to use HTTP trigger, but again, any button with an HTTP trigger is ignored in teams, you are only allowed to create actions for opening URLs, submitting, hiding parts and showing a secondary card.

Below the main part of the designer is the JSON, which is created by any changes you make above but also can be edited and reflected in the visualiser. The snippet below is taken from the standard card, which contains all the bits that need duplicating to ensure the new, improved approval works correctly.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


"actions": \[
 {
 "type": "Action.ShowCard",
 "title": "Approve",
 "card": {
 "type": "AdaptiveCard",
 "body": \[
 {
 "type": "TextBlock",
 "text": "Comments",
 "wrap": true
 },
 {
 "type": "Input.Text",
 "id": "comments",
 "placeholder": "Enter comments",
 "maxLength": 1000,
 "isMultiline": true
 }
 \],
 "actions": \[
 {
 "type": "Action.Submit",
 "title": "Submit",
 "data": {
 "Environment": "Default-2821cf92-86ad-4c7b-ba9a-5c79a70d4a21",
 "ApprovalTitle": "Appoval required for Opportunity",
 "ApprovalLink": "https://flow.microsoft.com/manage/environments/Default-2821cf92-86ad-4c7b-ba9a-5c79a70d4a21/approvals/received/6cce94f6-603c-40e7-adb6-8b20c75f724f",
 "ApprovalName": "6cce94f6-603c-40e7-adb6-8b20c75f724f",
 "ItemLink": "https://.crm.dynamics.com/main.aspx?newWindow=true&pagetype=entityrecord&etn=opportunity&id=b7c47c42-a290-e611-80e3-c4346bacba3c",
 "ItemLinkDescription": "Opportunity for 7-Eleven and Udaside label - ",
 "OnBehalfOfNotice": "Requested by Carl Cookson <CarlC@CRM.onmicrosoft.com>",
 "CreatorName": "Carl Cookson",
 "CreatorEmail": "CarlC@CRM.onmicrosoft.com",
 "CreationTime": "\\"2019-07-03T14:30:02Z\\"",
 "MessageTitle": "Appoval required for Opportunity",
 "Options": \[
 "Approve",
 "Reject"
 \],
 "SelectedOption": "Approve",
 "ActionType": 1
 }
 }
 \],
 "$schema": "http://adaptivecards.io/schemas/adaptive-card.json"
 }
 },

User Admin PowerApp (Part 1)

Mon, 10 Jun 2019 00:00:00 +0000

Sorry it has been a while since my last blog post, this scenario has taken a while to get it to the state where I was happy to show it off. Mainly due to my own lack of understanding of the intricacies of the D365 API, but also been busy external to the blog, you know real life.

Objectives

The Scenario (This part)
Notifying the manager of a new Employee (This Part)
PowerApp to display and update User Data
Update Roles and Teams

The Scenario

Big Energy Co is going from strength to strength, presumably because of the innovative solutions using LUIS, Alexa and IFTTT.

The HR department is ramping up recruitment and new teams are being shaped to support all the growth.

One of the criticisms from the managers is that it takes a while for the IT / D365 administrators to get users in the correct teams and security roles so they can be effective in D365.

A clever chap in the management team suggested that they be given an app that would allow a manager to update the roles and teams (and other relevant parts of a user) without resorting to logging into D365 administration. Something they can use wherever they have WiFi or a data connection.

It would also be good to get a notification when they have a new employee, or someone is added to their reports.

The Flow

This flow is quite simple, trigger an email when a user has the Manager field (parentsystemuserid) field updated. O365 will create the user for us (assuming you are in the cloud) and an administrator will still have to update the users manager.

Here, the attribute I am interested on is parentsystemuserid.

Next, just check to see if the manager is actually populated. In a lot of businesses, removing their manager is part of the process on off-boarding an employee, to tidy up selection lists etc.

Then, get the manager user record from D365 so that the email can be sent to it.

Told you it was simple. I am sure that this can have more logic - Do we need an approval step before assigning this user? Do we have to wait for HR to do some work and only activate the user once all the checks are done?

Next, I’ll step through the PowerApps set up to retrieve data from my reports.

Creating Attachments in D365

Sat, 11 May 2019 00:00:00 +0000

This isn’t one of my usual posts as I always like to start with a business case. I intend to create a blog about the business case / solution that created this issue once all the other pieces fall into place, so watch out for that (keep them keen by teasing they say)

The Problem

You might not know there is a problem, but there is. Squirrels are a problem, but not my field of expertise, @dynamiccrmcat will have other opinions.

Attachments are a problem. More specifically, trying to add an attachment to D365 via a Flow or PowerApp is a problem. Yes I know we should be using SharePoint or Teams etc, but sometimes you want to keep your data in D365.

You should just be able to “Patch” the Notes entity in a PowerApp with the file you want in the documentbody field of the entity, but you run into problems (bug) with objecttypecodes (it is expecting a GUID and all you know is an entity name).

@JukkaN pointed me to this article on the PowerApp forum which explains the problem in more detail and clearer than I have. This was via a conversation with him and @TattooedCRMGuy where we came to the conclusion that there is a bug in the CDS connector.

So my next thought was to call a Flow from the PowerApp, passing in the file as a parameter. This doesn’t work either. Any which way you try, it ends up with the file being passed as the link to the Azure blob the PowerApp is temporarily using to store the attachment.

Then I started using the developers friend, Google. My first thought is that if I could pass to the Flow a file rather than the URL, this would work. This thought led me to an excellent Youtube video by Paul Culmsee. He shows how to pass a Photo from PowerApps to Flow to save it to Sharepoint. He has the same issue, how to pass a file to flow, and thanks to him, I have duplicated it for saving a file to D365.

So the logic I have deployed is

PowerApps → Custom Connector → Flow → Custom Connector into D365

2 custom connectors here, this is a relative expensive solution, as the user require a PowerApps Plan 1 license for this which might be an addon to their license.

The D365 Connector

Starting at the final step, I utilised a custom connector like in my previous posts to interact with the D365 API directly. I am not going to go through the method of creating the connector, just this custom action. Again, PostMan is your friend. Using this tool, I generated a JSON template to post against the Annotations entity. Firstly, add an action to the connector.

Next, select Import from sample, and populate as below, obviously using your own instance API endpoint.

Couple of things here, Annotation is the name of the table that Notes are stored in. “objectid_contact@odata.bind” is the single value navigation for linking Contact to the note. In the CDS connector, this field is not visible, you are expected to enter a pair of _objectid_value and objecttypecode, which doesn’t work, hence this blog post (I hope they fix it, but not too soon now I have worked it out). Finally, documentbody is the field where the attachment is stored, as a Base64 string. This is weirdly different than the binary data store used by Sharepoint.

Select Import and the first connector is done.

The Flow

The flow is pretty simple, a HTTP trigger, messing around with the inputs and sending the information to the D365 connector. Simple, but I needed the video by Paul Culmsee to guide me through. The premise being, rather than the usual approach of looking at the body of the web call, we need to take out parts from the query string and the content of the call would be a file. He does a much better job at explaining it that I do, so head over to the video to actually learn.

A standard HTTP trigger. I then use a Compose data operation to take data from the trigger using a formula based on the query parameters passed.

trigger()[‘outputs’][‘queries’][‘filename’]

This states that I want find and store the filename parameter passed in the url when the trigger was triggered

The Get File Body does the same but looks at the content of the body that was passed in.

triggerMultipartBody(0)[’$content’]

The final part is a call to the D365 custom connector, passing in the compose operation outputs

Another Custom Connector

You can’t call a webservice triggered flow from a PowerApp directly. You can call a Flow, but the flow doesn’t pass the appropriate parameters. It only deals with strings. You can’t convert your file to a string in PowerApps. I am obviously going to be proved wrong here, but I will learn. That’s one of the reasons I blog.

Hence, why you need to create a custom connector to pass from PowerApps to the Flow above.

Connectors can be created by uploading a swagger definition. Swagger is an open-source framework to document APIs and has been recently converted to the OpenAPI specification. Obviously connectors can be built from scratch, but because of the file upload that is required, a definition of the API is required.

Paul again comes to my rescue, he has a great blog post that he goes through in detail the file that was produced to support his video. In the Youtube post, he uses a tool that I can not find, but this file walkthrough was enough for me to produce my own file. I am not going to go through the detail here, Paul does a much better job.

In custom connectors, hit the +, then select Import an OpenAPI file.

Give your new connector a name and select your newly created file definition. If your file is correct, you are now presented with a pre-populated definition of your connector. The query parameters displayed include lots of configuration items that should be pre-populated from your Swagger file.

You can see the connector is not expecting a Body.

If you test the connector action there is also an extra parameter it is expecting

This File parameter is essential. Now it’s reading for use!

The PowerApp

To demonstrate the connector, create a new PowerApp. Because this is for the contact entity, use a drop down to get a list of Contacts to attach the note to from D365.

Associate this with D365 using the Common Data Service

Select the Contacts Entity, back in the properties of the control, use Full Name as the Value. Next, add a “Add Picture” control.

Also add a datatable. This time connect to the Annotation (Notes) entity in D365. Make sure you use the D365 connector though. For some reason, the Common Data Service connector does not return the Regarding as a field you can use. Select a few relevant fields, Title, Note, File Name and Document.

In the Values field, filter the datatable by the Contact that is selected in the dropdown and only show those where there is an attachment.

Filter(Notes, Regarding = GUID(ContactDD.Selected.Contact) && !IsBlank(Document))

Selecting a contact now should deliver a list of notes that are attached to that record.

To Upload a document, add a button. This will trigger the custom connector, so this needs to be added to the PowerApp. Select Data sources, add data source

The custom connector that was created earlier should appear. Select it.

In the button OnSelect action, if all is well, enter the name of the connector and action and it should give you a list of parameters you need.

The final call to the connector looks like this

FileUploader.UploadFile( AddMediaButton1.FileName, ContactDD.Selected.Contact, “Added from PowerApps”, “Added from PowerApps”, UploadedImage1.Image ); Refresh(Notes)

The filename comes from the control within the Image upload control, the contact Id is from the selected contact, some text stuff to fill out (you could add a text control to take that input obviously) and then the image.

I refresh the notes data set after I am done so that the list has got the data.

So that’s it, a complicated solution to a “bug/feature” currently in Powerapps.

A screenshot of that squirrel note against the contact in D365, just so you know I am not bluffing.

BTW, squirrels are evil, rats with marketing, don’t believe everything @dynamiccrmcat says, though it is probably just squirrels she is wrong about.

IFTTT Flow D365

Sat, 04 May 2019 00:00:00 +0000

This will be a quick post, as the connector doesn’t take a lot of configuration.

The Business Scenario

Big Energy has a lot of sales people, all over the country, which make a lot of calls, usually on their mobiles, to potential or current customers, arranging opportunities and resolving any issues.

The Sales Director at Big Energy is concerned about the number of calls that the sales people don’t always log those calls, only when they deem it important and have no traceability about how many calls an individual has made.

Could a solution be found that would log every call a sales person makes to a number D365 knows about?

IFTTT

IFTTT (IF This Then That) is a free web service that allows users to create applets to connect their devices with their services. There are lots of sample applets to automate tasks, my favourite is linking Alexa’s shopping list with Tesco to add everything I add to Alexa to my Tesco order. Simples.

IFTTT works with a lot of devices and it has a stand alone app for smart phones, allowing interaction with the device.

Getting Started

Search for phone, and select Android Phone Call (sorry think this is only Android users)

This presents you with several triggers, the IF part. Select Any Phone Call placed. You will have to make another App for received, but same logic.

The next step is to tell IFTTT what you want to do, select the big That button

IFTTT lets you search for all the available services that you can trigger from your data. Search for Web and select Webhooks.

The only option here is to make a web request.

If you have read my previous articles (if not go here or here now and shame on you), creating a Flow trigger from a web request should be straight forward.

Create the Flow

As in the previous articles, start with a generic http trigger in Flow. Firstly, select HTTP trigger, and enter a default body for the JSON. This is generic enough to allow the call so the schema passed from IFTTT can be created.

As the action, send yourself an email, with the Body of the email being the body of the request.

Hit save and go back to the trigger. This URL is the bit you need to pop back into IFTTT.

Connecting Flow and IFTTT

Back in the IFTTT Web Request, paste in the URL. I have changed the Method to Post, content type to json and included in the Body 3 ingredients (data returned by the call placed method trigger into the body. This is formatted appropriately to become a valid JSON Request

This is now ready for testing.

Testing

For testing to commence, a call needs to be logged. This means you need to install the IFTTT app on your phone, log in and check the app you created is available.

Once this is done, make a call.

If successfully, your Flow should run, sending you an email. If not, you can look in the IFTTT log by checking the activity log.

The log highlights what happened for each run, when it was updated etc. Not as user friendly as Flow, but at least you get an error code. I found I was getting 400 errors, as the format for the JSON wasn’t correct.

My email also has the information sent from the request, this is used to tell Flow properly what is expected, allowing access to the properties.

Is the Contact known?

The assumption is that not all calls made by the user will be to known contacts. Either unknown to D365 or personal calls. The first thing that is required is to find the contact. Using the List Records component, use a filter query to return all contacts that match the data coming from IFTTT with any of the phone numbers held against contact. Be careful here, as the number as entered by the user in the contact on their phone or as dialed is used here.

The next step is to check if any contacts were found. As previously, check the length of the return from the previous step has one or more contacts in it. Add the contact id to a variable if contacts were returned, terminate with grace if not.

Create the Phone Call

Creating the phone call is a straight forward call to the CDS Create Record action.

Couple of formulas here, firstly the timestamp that comes from IFTTT looks like

May 01, 2019 at 05:50PM

Flow doesn’t like this, so the expression for Due is

replace(triggerBody()?[‘occuredat’], ’ at ‘,’ ‘)

Duration from IFTTT is in seconds, in D365 is minutes. A simple divide by 60 puts in the right value

div(int(triggerBody()?[‘callLength’]),60)

Flow is complete.

Can it be be recorded better?

The call that Flow creates is missing 2 key components, the From and To

The CDS connector doesn’t support activity parties (these fields are both party fields, the user can type and search for multiple contacts, users, leads etc to populate this normally). You can get at these via standard API calls, so back to the custom connector.

My previous post on LUIS used a custom connector to close the incident using an action. This walks through creating the connector, so I won’t repeat myself.

I will step through the specific action for creating the call, as it isn’t straight forward. Further, Postman is still your friend. The only way I managed to get this configured is relying on this great tool.

Using Postman, the format of the JSON can be defined, based on the API reference for Phonecalls. This highlights that activity parties are created, and associated with the call to create the phonecall.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


{
 "subject": "CC Test",
 "scheduledend": "2019-05-01 12:00",
 "regardingobjectid\_contact@odata.bind": "/contacts(A651968A-5660-E911-A973-000D3A3ACAF8)",
 "directioncode": true,
 "scheduleddurationminutes": 6,
 "phonenumber": "test",
 "phonecall\_activity\_parties": \[
 {
 "partyid\_contact@odata.bind": "/contacts(A651968A-5660-E911-A973-000D3A3ACAF8)",
 "participationtypemask": "2"
 },
 {
 "partyid\_systemuser@odata.bind": "/systemusers(C3AE1146-AD6D-E911-A984-000D3A3AC0C2)",
 "participationtypemask": "1"
 }
 \]
}

Take this JSON body and copy into a new action in your custom connector.

Enter details in the general page, just enough to uniquely identify your action. Of course, you need to be a bit more descriptive if you plan on shipping out the connector.

Select Import from Sample, Select Post, the URL should be just PhoneCalls, paste the JSON above into the body

Flow does some magic and now you can update your connector. I tried testing this, but got a little confused (me of little brain) so I assumed that Flow is good and would handle it and went straight to using the connector in Flow.

Back in Flow, select a new action, custom connector, the new one you just created and the action established.

The populate as below. I know the parameters are not the best names, someone with a bit more time would have tidied this up.

These are the same formulas that were used earlier. You need to add the “/contacts(” etc to each GUID as the data bind requires it.

Run the Flow and just like that, the Phone Call is created in D365 with a Call To correctly established.

Call From is missing, IFTTT doesn’t let the Web call know who called it. I have searched, but IFTTT is meant for home grown activity, so if you have registered the app, you should know the call. The easiest way around this is to pass in a hardcoded value (email) specific to the end user so a System user can be looked up and populated in the parties field.

Alexa, Field Service and Me (Part 3) - Creating Work Orders

Thu, 25 Apr 2019 00:00:00 +0000

This is a continuation of my series on a proof of concept to allow Alexa to interact with D365 Field Service

Objectives

The Business scenario (Part 1
Create an Alexa Skill (Part 1)
Connect the Skill to D365 (Part 2)
Use Field Service to book an appointment (This Part)
Return the information to Alexa (Part 2)

In this final (unless I need to expand on the scenarios) part of the story, Flow will be used to take the information garnered from the user and create a work order.

Calling a Sub-flow

The original flow was all about Alexa, but what about other voice assistants? Flow is no different that any other programming languages and as such we can use the same concepts to writing decent flows, one of them being re-usability. If the code to write the Work order and book it is generic, it can be re-used when Google or Siri is connected to the application.

To this end, the Flow starts with another HTTP trigger, which is called from the previous flow.

Just like when connection Flow to Alexa, the URL is required in the child to update the caller. Create a new Flow, using the When a HTTP request is received. As content to the JSON Schema, add just enough to get you going and use the output to send an email so that the schema coming from the parent flow can be seen. This is a repart of the logic used to start our parent flow.

Once saved, the URL will be generated in the trigger step. Use this to call the child Flow from the parent. This is the HTTP action. The Method is a POST, the URI is the trigger URL defined in the child Flow. No headers are required. In the body, add in the things that are already known, just to ensure repeat calls to D365 are made. The Intent is also passed in, which has all the details about what the user wanted.

Now ready for testing, ensure both Flows are in Test mode and trigger Alexa. After a little delay, an email should be sent in the child Flow detailing enough information to create a Work Item.

Use this email to populate the JSON as previously, easily creating the schema that is required.

Creating a Work Order

Next, get the Account the contact is associated with. This is done with a call to the D365 Instance using the Common Data Service Connector.

A Work Order needs some fields to be set before it can be save, Work Order Type is one of them. This could be hard coded, but Alexa has supplied the intent. To match the Work order type with the intention in Alexa, a field on the Work Order Type was added, Alexa Intent, which is searched for in the CDS List Records action.

To make the Flow easier to manage and reduce the dual looping, the Work Order Type is returned to a variable

Once the data for the new Work Order is available, create the Work Order using the CDS Create Record connector.

Most of these are obvious, but the one that is not is the Work Order Number. In Field Service, this is automated, with a prefix and a number range. As this doesn’t work in Flow, a work number is generated using a random number, using an expression.

rand(10000,100000)

A few other parts of the work order are populated, helping the service manager to match the time as appropriate.

Alexa, Field Service and Me (Part 2) - Linking to Flow

Sat, 20 Apr 2019 00:00:00 +0000

This is a continuation of my series on a proof of concept to allow Alexa to interact with D365 Field Service

Objectives

The Business scenario (Part 1)
Create an Alexa Skill (Part 1)
Connect the Skill to D365 (This part)
Use Field Service to book an appointment (Part 3)
Return the information to Alexa (This part)

In this post I will be linking Alexa to D365 and returning some information back to the end user.

Receiving information from Alexa

Alexa interacts with the outside world with a HTTPS request. Once Alexa has determined that it understands the user and they have asked for something of your skill, it posts to the web service you have configured.

That API Guy had a great post where he links his Alexa to his O365 email account and has Alexa read out his new email. This article steps through linking Alexa and Flow, and it showed me how simple that part of the integration is. Microsoft has done the hard work by certifying it’s connections, you just need to create one.

Flow provides several methods of subscribing to HTTP events, but the one we are interested in is at the bottom

The URL is generated for you, and is the bit you need to post into Alexa Skill configuration once we have created the Flow. In the JSON schema, we just want a stub for now. The schema is defined by Alexa and how you configure the skill. It is best to get the connection up and running and use the initial call to substitute the schema later.

Every Flow needs at least one action to be able to save, so to aid testing and understand the JSON sent by Alexa, the first step is to send an email to myself with the content of the call.

Saving the flow and go back to the trigger

A specific trigger URL for our Flow is now generated.

Back in Alexa

In Alexa, on the left in the Skill is Endpoints. Alexa allows different endpoints to the skill depending on the Alexa region as well as a fall back. As this is a POC, using the default is appropriate.

The important part of this is the drop down below the URL copied from Flow, this needs to be the second option “My development endpoint is a sub-domain of a domain that has a wild card certificate from a certificate authority”. Basically, Microsoft has certified all their Flow endpoints with wild card certificates, allowing Amazon to trust that it is genuine.

One saved, Build your skill again. I found every time I touched any configuration or indeed anything in Alexa, I needed to rebuild.

Testing

Ready to test. Alexa allows you to test your connection via the Test tab within your skill.

You have to select Development from the drop down. You can also use this interface to check Production skills.

A word of warning, everytime you build, to test that new build, I found I had to re-select Development in this window by toggling between “Off” and “Development”.

Back in Flow, test your flow by confirming that you will conduct the action.

In the Test panel in Alexa, enter a phrase with your Invocation and Utterance in Alexa entry and if Alexa understands it is for your invocation, your flow should be triggered! Alexa will complain, as our simple flow hasn’t returned anything to it. We’ll worry about that later.

In our simple Flow, I used email as the action, as can be seen below.

This is the raw JSON output of the Alexa skill and this is used to tell Flow what to expect. This way it will provide the rest of the Flow with properties that are more appropriate.

Back in the Flow trigger, select Use sample payload to generate schema, which presents the text entry, where you paste in the email body.

Flow does the hard work now and presents you with a schema for what Alexa is sending your Flow

Authenticating the user

Taking triggers from Alexa, hence a user is all well and good, but they expect a rapid response. Alexa Skills are public domain once you publish it, anyone can enable your skill, hence a little work needs to be done to understand who is calling our skill and whether Big Energy Co supports them.

Which User is it?

The request from Alexa does include a unique reference of the user, but normally businesses like Big Energy Co work on email addresses, which you can get from Alexa, but the user has to give you permission. This can be pre-approved when the end user installs the skill or you can ask for approval.

Alexa needs to be told that your skill would like this permission. This allows Alexa to request this permission for you when your skill is enabled by the user

On the left hand menu, there is a Permissions link, where our skill asks for the email address

To ask Alexa for an users email address is a seperate web call with properties from original message sent from Alexa in the trigger.

Alexa provides each session an access token so that Flow can ask for more information from Alexa in the context of the users session, location, names, email etc. As this is a globally distributed system, the api End point can vary depending on where the user started their session. The URI at the end asks for the email address of the user of the session.

Alexa may refuse to return the email address, because the end user has not given permission for our skill to share this information. If the call to get the email was a success, it means that Alexa has returned the value and the Flow can continue

Without the permission, the call fails and so the Flow captures this. Remember to set a run after for this step to ensure it still runs on failure. Otherwise the flow will fail not so gracefully.

Alexa provides standard permission request functionality, the Flow responds to the original call with this detail in a JSON formatted string, with the permissions the Skill wants listed. Finally, for this failure, let the Flow terminate successfully. The Flow can’t continue without the information.

Does Big Energy Co support the user?

It is not enough that the user has asked us for help, they need to be known to Big Energy, as a contact. Querying D365 for this data is the next step

Using the D365 connector, query the contact entity for the email address that Alexa has given us.

A conditional flow checks to see if the return from the Retrieve Contact step has a single record using an expression below

length(body(‘Retrieve_Contact’)?[‘value’])

Responding to the user, quickly

Like any Alexa Skill, the user expects an immediate response. Flow in itself is quick, but when it comes to updating or creating records, it can take seconds. The timeout for your response to Alexa is 10 seconds, which isn’t a lot when you want to look up several things to create the appropriate work order.

To get around this, respond to the user once you know you have all the information you need to create the appropriate records in D365. Here, the Flow responds if the contact is in our database. In production, you could do some more checks or just assume that if the contact is known, the logic could create an opportunity to sell them a contract if nothing else. Equally, terminate gracefully after responding that Big Energy Co doesnt know the customer, prompting them to ring the service desk.

In the switch statement, a response to the user is built up. Specific, personalised responses using the data you have retrieved is essential to give the customer an understanding that you have received the request and will respond.

The responses are short and to the point but personalised to the customer and what they asked for with some expressions to add more information if they told Alexa.

This snippet adds after “request for a Service” what the user asked for a service on, relying on the JSON formatted values.

if(equals(triggerBody()?[‘request’]?[‘intent’]?[‘slots’]?[‘device’]?[‘value’], ‘’), ‘’, concat(’ for your ‘,triggerBody()?[‘request’]?[‘intent’]?[‘slots’]?[‘device’]?[‘value’]))

This snippet adds to the end a sentence including the date that the user asked for.

if(equals(triggerBody()?[‘request’]?[‘intent’]?[‘slots’]?[‘date’]?[‘value’],’’),’’,concat( ‘We will endeavour to send an engineer on ‘,triggerBody()?[‘request’]?[‘intent’]?[‘slots’]?[‘date’]?[‘value’]))

Finally, for the Alexa response part, the Flow returns a response to the user. This combines the body with a little standard text. This is what Alexa will say. You can also add a response to the screen for those devices able to do that.

The final part of this flow goes on and creates the work order. I seperated out the flows using a sub flow, which is discussed in the next part of the blog.

Alexa, Field Service and Me (Part 1)

Fri, 19 Apr 2019 00:00:00 +0000

As we all now have smart devices in our home, linking them to business applications could be a key differentiator between winners and the also rans. This series of posts will demonstrate how I connected Alexa to D365 Field service.

Objectives

The Business scenario (this part)
Create an Alexa Skill (this part)
Connect the Skill to D365 (Part 2)
Use Field Service to book an appointment (Part 3)
Return the information to Alexa (Part 2)

Our Scenario - Big Energy Co

Our generic big energy company is diversifying into support and maintenance of home energy products, boilers, central heating, plumbing, electricals and numerous other aspects of a consumer’s home life. A client will ring up, tell the support desk that they have an issue with the appliance and the employee will book a suitable engineer in to come out to their home. This is all done via Field Service in D365. Big Energy also have scheduled servicing of Boilers on an annual basis.

What the CTO wants to do is embrace the in home virtual assistant to promote Big Energy as a forward thinking organisation which is at the forefront of technology to allow Big Energy’s customers to book an engineers visit via their smart device. Her expectation is that Alexa, Google Home or Siri will allow a service call to be booked without talking to the support desk. This will allow meaningful interactions with their customers 24/7.

The proof of concept will start with the front runner in the war of virtual assistance, mostly because I have one.

Alexa

If you have read my introduction to LUIS in Alexa Skill concepts are a mirror of the concepts introduced in LUIS. Alexa has Utterances & Intents. Entities are called Intent Slots for Alexa. Alexa has also got another concept, that being the Invocation.

First off, get yourself an Amazon account & sign up for the developer program at developer.amazon.com. This is all free. People can buy skills, but not sure Big Energy’s customers would think this is appropriate.

Use the Create Skill button, enter a name & select a language. I also choose Custom & Provision your own to allow us to send data to Flow which is hosting our integration.

Then I select Start from scratch, none of the others seem to match our scenario

Invocation

An Invocation is the starting point and is the differentiator between you and every other Alexa skill out there. It is effectively a name for your skill, what the user would say to call your skill. I have slightly altered my invocation to put some spaces in there so it is more natural to the end user.

Intents

Like in LUIS, intents are a category or what the user is looking for or asking. You can have many intents per skill. In our scenario around home appliances the user can ask for a service, a repair or an emergency as a starting point. Let’s start with a request for service.

Utterances

Utterances are samples to train Alex to understand the intent in natural language. Add as many utterances as you like as samples of how a person would ask for a service or repair, but ensure they are different.

Slots

In my sample utterances above you can see I have added Slots. Slots are the same as entities in LUIS, data that the user gives us when they are saying their utterance in addition to the type of thing they want.

Each Slot has a type, and I have used the default Amazon types except for device, which is a custom one.

Slot Types

Amazon has 43 of it’s own list types or 6 built in types for numbers & dates, but devices are not in the list. I want to know what type of thing the engineer is going out to fix, not sure I need to be that specific, but would be good to know if I need to send an electrician, gas engineer or plumber. I have added my own Slot Type, called it device and I now list the values I expect.

You also should also enter synonyms, not everyone calls it a telly, just us northeners.

Once you have entered enough intents & utterances, time to build and test. A nice message lets you know when it is done building. Ready for the utterance profiler or testing

Utterance Profiler

In the top right, is a pop out to test your utterances. Enter an utterance you haven’t used before to check you are getting the expected results.

The text I wrote is in blue, it has decided that this is a service intent, with a device of boiler & the day of wednesday.

You can carry on fine tuning your utterances, intents and slots to get the most accurate model. Like any language understanding, this will be an ongoing model.

This is Alexa done, we have configured everything we need to in Alexa, apart from our link to Flow. This needs a bit of pre-work in Flow to activate, in the next post.

Connecting LUIS & D365 (part 4) - Custom Connector

Wed, 03 Apr 2019 00:00:00 +0000

In my previous post, the fact that I had to “fudge” the routing and closure of the case irked me. Whilst at D365 EU Summit in Amsterdam, I spent an hour listening to Serge Luca (his excellent blog is here). He inspired me to think that we could close this loop using a Custom Connector in Flow connected to our D365 instance, allowing an API call directly to the closure action.

Back in the UK, I did some digging, found another excellent blog from Andrew Butenko which steps through doing this for Won Opportunity here, so just to complete the circle I will step through how I did this.

Create the App in Azure

This is a bit heavy for a citizen developer & in the real world you will have to ask your O365 admin to do this, but in my trail I have the appropriate access.

Go to portal.azure.com & log in using your CRM Admin credentials.

In the left pane, select Azure Active Directory, then App Registrations (Preview) then New registration. Give it a name, select Accounts in this organizational directory only & enter localhost as a temporary redirect URL, this will change later. Select Register & allow Azure to do it’s stuff

On the next screen, select API Permissions, then Add a permission

The one we are interested in is Dynamics CRM. Select it.

Check the box next to user_impersonation. Select Add permissions & now you should have 2 permissions for your new application. Now we need to ensure only we can access it.

In Certificates & secrets, select New client secret. Give it a Description and decide how long you want to wait before it expires. Not an issue for our demo, our trial wont last as long as this expiry. Once created, make sure you copy the value information, you won’t be able to retrieve this at a later stage.

We also need the application id, this is available on the Overview tab

Create a Custom Connector

Back in flow, under Data & then Custom Connectors there is a Create custom connector drop down, select Create from blank and give it a name.

On the next screen, you can customise the description & logo if you want, but the important bit is the Host, which is your instance url, and the Base URL which is the api access path.

Select Security next & choose OAuth 2.0. Identity Provider should be Azure Active Directory, Client Id is the Application Id from previous & Client Secret is also from the previous step. Login URL, Tenant ID & Scope should be left to their default. Resource URL is the url to your environment.

Save the connector by using the Update Connector now. There is an important piece of information, the Redirect URL, which we have to copy & add to our connector back in Azure.

Select the App Registration in Azure, select Redirect URIs

Add a new one from your copied redirect (I think it is standard, as I have only seen one, but just to be sure)

The next screen allows you to add Actions & triggers. I think there could be a whole new blog post on using triggers this way. As custom connector is generic across all apis, the flexibility is great. Select New Action.

The General section describes the connector in Flow, so useful but nothing special is required apart from the Operation Id, which is what api action you want to call & must be unique within each connector.

Select Import from sample. This would usually be a sample JSON function. I built mine using Postman, and this is a bit more than a citizen developer would be able to handle without experience. Federico Jousset has a great blog post on using Postman to “play” with D365 end points, including a link to an extensive Postman collection with lots of examples which were the key to understanding the call, particularly the parameters.

When you hit import, you will get this section under Request. The bit we are interested in is at the bottom, the body.

Click on body, then edit you will see a list of the parameters that Flow inferred from the sample body we gave it.

Select Incident Id for example, we can now give it a little more information & more importantly give the end user of the low more information with the Title & default value & whether it is required

We are now ready to Test. Select the test button, choose New Connection & connect to your D365 system. Enter the appropriate values, but be careful over the incident Id, as it is expecting a odata conversion. Someone better at connectors could tell me why.

If everything is good, you will get a blank body response back, as this is how the CloseIncident works

Using the connector in Flow

In the previous article, I showed you how we had to use a custom field & workflow in D365 to close the incident. I can now replace that with my custom connector call

Where I was updating a record because they were asking for their next bill, I remove the change to the CloseByFlow field and replace it with a seperate call

In Flow, I add a new action, select the Custom Tab, my connector & the action I want, this case the CloseIncident. We need to mimic how the api is expceting the Case Id to be passed, which is why we send with the ‘/incidents(’ prefix & ‘)’ suffix.

Test the flow & we have now completed the scenario. Case closure is now part of the flow.

Custom connectors are new for Flow & give the Flow creator that step extra of functionality where the OOTB solutions don’t work.

There is a word of caution about licensing here, I have been using a trial of E5, which gives you Flow for Office 365 License. I can create a custom connector to a standard application but not a custom application with it. This is the same for Flow for Dynamics 365, so I don’t need an extra license, but be warned.

Connecting LUIS to D365 (part 3)

Tue, 02 Apr 2019 00:00:00 +0000

In this 3rd installment of the series devoted to using Language Understanding (LUIS) to categorise emails via Flow, I will describe some of the parts of the D365 solution and walk through a final version of the Flow to extend its capabilities.

This blog has at least 3 parts, but overall the posts objectives are

Give you an understanding of a real-life scenario where we could implement LUIS – (Part 1)
Introduce you to the concepts of LUIS (Part 1)
Discuss the Microsoft Flow to connect LUIS to D365 (Part 2)
Give you some next steps on how you can try to bring LUIS into your organisation

Routing the case

Standard Save and Route functionality only fires automatically on case creation, or when a user manually hits the button. This action is available in workflow, but not in the CRUD actions of the D365 or CDS connectors. To get around this there is a workflow triggered of the change of the subject field which calls the OOTB action ApplyRoutingRule. This effectively is the same as the user clicking the button.

The routing rules are very simple, routing the case based on the subject selected.

Adding information from the case

In our scenario, based around a support desk for a large power company, one of the common requests is to provide meter readings. This data is invaluable.

In LUIS, this information is called an Entity. You can configure entities for each of the Intents to denote some parcel of information that the user is telling you on top of the intent of their email.

As you start typing and enter data, LUIS recognises this and replaces the data with a data type that it will use.

In Flow, the return from LUIS will contain a list of all the entities it has found in your utterance. The flow then updates the case with this defined data, in a separate field on the case record.

The first part of the flow checks the length of the array of entities that LUIS returned. If there are no entities, then just do a normal update of the case record. If there are entities, loop through them

As the entities array is looped through, check that the entity is a number. LUIS could return you a date or name. If it is not a number, just do a normal update of the record.

If it is a number, pass the meter reading to the case update in the new field on the Case entity.

This approach does lead to duplicate updates, 1 for each entity it finds. You may be better suited to extend the logic in a production system to prevent this.

Auto-reply for common intents

In our scenario, one of the common requests that the help desk gets is to ask when the end user is due a bill. This again could be dealt with in numerous ways via workflow in D365, but doing it in Flow allows the demonstration of Flow’s abilities.

The first part is to check the Top scoring intent is “Next Bill due”. The flow goes on to check for meter readings if it isn’t.

Using D365 connector this time (Microsoft changes so quickly, it is hard to keep up with what the best methods are) I retrieve the contact that created the case then send them a nicely formatted email. This will send the email as the account you attach to run the flow, in our scenario the support desk. I have only hardcoded the content here, but you could easily read the date of the next bill from the users account record or something similar.

The next step is close the case as we have provided the end user with the appropriate information. In D365, this is another action not readily available via the CRUD of the CDS or D365 connector.

I now realise, after attending the EU D365 User Group Summit that this would be possible via Flow, along with routing the case, if you create your own custom connector and associate that with your D365 API instance, but that’s for another post.

To get round the limitations, a new field is populated on the Case record, Close from Flow.

A workflow is then triggered when this field changes to call the OOTB action if the value is true.

Sentiment analysis

One of the big uses for social engagement and monitoring is to assess sentiment in the comments made by customers. LUIS provides this information in a textual (positive, neutral or negative) as well as numeric form if enable it on the application.

Once you have this configured, recording this against the case and maybe setting a priority on it’s value would be quite straight forward.

Connecting LUIS & D365 (part 1)

Sun, 31 Mar 2019 00:00:00 +0000

As Microsoft wants us to consider using AI in all aspects of our developments, I wanted to see if I could use one of the cognitive services available to life in a real life scenaro.

This post & it’s other parts will

Give you an understanding of a real-life scenario where we could implement LUIS
Introduce you to the concepts of LUIS
Discuss the Microsoft Flow to connect LUIS to D365
Give you some next steps on how you can try to bring LUIS into your organisation

The Scenario - Big Energy Co

Imagine a busy helpdesk or contact centre at one of the big electricity or gas companies. They are inundated with calls, emails & chats from their customer base to request numerous changes or additions to their account, provide meter readings, complain or numerous other concerns.

Email is one of the biggest mediums for support when the matter is not urgent. The standard email to case conversion is commonaly used to bring these support requests into D365 CE.

But that is traditionally where it stops. A 1st line support user would have to read the content of the case, decide on the appropriate subject for the new case & select save and route. This takes time, upto a couple of minutes, of invaluable time of an educated, talented member of your team.

LUIS - Language Understanding

LUIS is Microsoft’s cloud-based API which tries to understand the meaning behind phrases. LUIS could take a paragraph of text and categorise it to suggest what the writer of the paragraph is trying to say. Bringing machine learning into your app can drastically reduce the time spent scouring tet for meaning .

In a 1st line support scenario, an email comes into a support mailbox and D365 will create a case with it’s auto-creation rules to allow a 1st line support person to read the email, decide what the email is concerning, then route the case to the relevant team.

Using Flow and LUIS, we can automate this step, reducing the time taken to get the case to the right people, improving SLAs and reducing costs.

LUIS Configuration

For all of this, I am using a trial environment, Microsoft makes it easy for you to play with all it’s tools, and LUIS is no exception. The free licenses gives you 5 text requests per seconds, definetly adequate for development and trial purposes. It is then £1.11 per 1000 transactions above this, with a max of 50 transactions a second.

By going to luis.ai & logging in, you will be allowed to create an app. This is the starting point. As you can see my app has been created already.

Intents

Intents are the term for meaning within the app. Each app will have several intents, what are the likely short description or categories of why an email would come into the environment?

Utterances

Each intent has several utterances, which are phrases from which LUIS will learn and define the intent of the text passed to it. It is very simple to add utterances and you should aim to get 15 or so for each intent as a starting point.

You can add as many utterances as you like, try to keep your utterance count consist between intents as a higher utterance list on one of the intents will lead to it be chosen more, in effective giving you false results. When you get into a near production scenario, you need to keep adding them from feedback from your users. You could enact a process which, when LUIS fails to assocaite an intent to a case or gives a false classification, this is highlighted for a BA to analyse & apply to the model.

The next thing to do is train LUIS. This brings any changes you have made into the AI so they also can be used to understand the conversation.

Training is complete when you get a green bar across the top.

Now we have a model, let’s test it, using the inbuilt Test functionality available from the top right.

If you type a string in the box provided & hit return, you are calling LUIS and the text will be analysed and LUIS will reply with the highest intent & how likely the phrase enters matches it.

I have entered the phrase “can you help me transfer my account”, which wasn’t part of the utterances I created earlier, but closely matches one of the Account closure utterances.

Looking at the response, LUIS is stating that he thinks this phrase is about Account Closure and he is 58% sure that this is correct. If you click on the Inspect link you can use this to train LUIS if the response is not correct by using the Edit link, adding an utterance to one of the other intents or reenforcing the entered text was in the correct intent.

Publishing LUIS

My LUIS app is ready, it is trained and raring to go. Now we need to allow access from the publicly available API. The Publish button steps you through the process, ensure you go to Production. Don’t worry about costs for now, you get 5 requests a second for free, which is great for trialling & developing

In Application Information, there 2 key bits for connecting LUIS to Flow. Firstly, the Application ID is the key we want later. Secondly, we need to ensure anyone with the Application ID can access our endpoint & use the app we have configured, so ensure the Make this app public is checked.

This is a little less secure than you would want in production and there are details about LUIS security available to ensure only the proper users can access fully documented here.

That’s it, ready to go. In the next part, I will configure D365 and Flow to complete the scenario

Connecting LUIS to D365 (Part 2)

Sun, 31 Mar 2019 00:00:00 +0000

In the first part of this blog post I explained our scenario for Big Energy Co and it’s desire to improve efficiency in the support desk, introduced LUIS and the core concepts around utterances and intents, configured LUIS to allow it to understand the intents we need and published the application.

Now I need to connect LUIS and D365 to allow automatic classification and routing of cases based on Natural Language inspection of the body of the case.

This blog has at least 3 parts, but overall the posts objectives are

Give you an understanding of a real-life scenario where we could implement LUIS (Part 1)
Introduce you to the concepts of LUIS (Part 1)
Discuss the Microsoft Flow to connect LUIS to D365
Give you some next steps on how you can try to bring LUIS into your organisation

Nowadays, Microsoft Flow doesn’t need an introduction - it is the cornerstone for the whole of Microsoft Power suite (not sure why it doesn’t get the Power prefix) and allow spot integrations between one or more disparate applications. It also allows you to “program” some data transformation or logic to control how data flows between applications or actions to take in specific circumstances. Flow is a complex beast, but simple to use in a lot of cases.

The Flow

As you can see, the flow is pretty simple. We get a trigger from D365, strip the body of the case down to raw text, check to see if have anything left, ask LUIS to predict what it is, check how confident LUIS is, then update the case again. This is a simple flow which isn’t production ready by any means, but shows you the power of Flow and is enough for you to get started

Triggering from D365

Our first step the trigger from D365

I am using the Common Data Service connectors here, which are the future, so why not? We have to connect to our D365 environment, chose the Cases entity and give it a scope. This is new for the CDS connector and allows a lot more flexibility around what data runs through a flow. You could keep the data to one business unit in an organisation, useful if you have country specific flows for example.

Stripping that nasty HTML

Email contains lots of formatting information that LUIS doesn’t understand. CSS, html tags, that heading etc will really upset LUIS, but handly there is an action to return just the actual words. Pass the body of the email, the case description to it.

Also in this snippet, I am setting up a variable for use later on, to store the Subject ID.

Checking for empty email

Another thing that LUIS doesnt handle is sending it an empty request. Just for a bit of house keeping, if, after stripping out all the html tags, the content is empty, rather than calling LUIS, exit gracefully. Always have in mind when running any flow that someone will be bombarded with error alerts if you don’t check

Passing to LUIS

In the previous post, when your LUIS app is published, you get a GUID representing the Application key. When you first connect to LUIS in Flow, this is what you need. If you have many applications in LUIS on that key, Flow wants to know which one, and also which version. This is handy if you are training LUIS and the new version isn’t quite ready, stick with a previous version of your app.

The Utterance text is the email body, stripped of the html, which LUIS is to analyse.

Is LUIS confident?

Like any AI product, LUIS can only predict what it thinks is the likely intent of anything you pass to it. It provides you with a score, 0 being not confident, 1 being overly confident that matches each intent. We basically use this as a percentage. When this returns to flow, LUIS provides the top scoring intent as well as the top scoring intent score. If LUIS isn’t confident that what you have sent it, then Flow shouldn’t update the case. This case should stay with the 1st line queue for them to resolve.

Again, this is about making your code production ready. It would be quite easy to trigger additional steps here to ensure this case is looked at and maybe a training point for LUIS after a human decides on the best route for the case.

Retrieve the subject

The subject tree in D365 matches the intents. This is a key point for our process to work. You could use other factors or matching, but this is pretty simple.

Using the CDS link, we use the List Records feature to query the Subject entity. The filter query is the key here, using a piece of OData query notation to find the subject with a title that matches our top scoring intent.

Though we will only retrieve one record, the List Records action will always return an array or records, an array of one. To keep your flow in one column, you can set a variable with the value of the subject Id you have retrieved and use this going forward. If not, you will have to do the remainder of these steps within the Apply to each action.

Updating the Case

The last part of this simple flow is to update the case back in D365. Using the Id from the originally triggered case, we update parts of the case.

The description is updated with the html stripped text. There are lots of ways to do this in D365, but seeing as we have done it already, it is neat to use it again. I have also added a new field on the case to log how confident LUIS is. This could be used as a summary later or for managing the training of LUIS.

Finally, the subject Id is passed to the Subject field.

So that is our flow complete. Now for some testing.

Testing our Flow

Flow has some really neat tools to ease testing. In the right corner, is the Test button which gives us this panel. The first time you run a flow, you will have to perform the trigger action, sending in an email to convert to a case or creating a case in our scenario, but after that, we can use previous data. Great for tweaking & checking

If you run a test, you will hopefully get a screen with lots of green ticks next to the parts that ran successfully as well as some crosses against those that didn’t.

If you drill down to each step, you can see the input and the output from that action.

In this example, you can see the original html formatted input from an email as well as the output of just the text.

The call to LUIS shows the JSON return from LUIS. The LUIS connector gives a lot of properties transformed out of this content.

The CDS record update shows only the fields that we update, a standard D365 API call. You can see the Subject ID being set, as well as the html stripped description and the Intent score.

So, flow done. In the next installment, I will show the D365 implementation, how we bring it all together. I also take LUIS and flow a little bit further, to add more complexity and functionality to the both to improve the scenario.