A few points about the design. The solution is an D365 CE solution. I started to consider to use the existing Territory records but felt that there would be enough situations where a web channel Lead may not have a clear path to being assigned to a specific Territory should there be an automated Territory assignment active. What would happen to those leads without a Terrirtory - be forgotten?
So, being a SMB client, I designed the solution based around a Sales team where there would be one manager for the sales team. One can create a Team from Security section. The key for this flow example, is to assign an Administrator (user) that has a validated email. The Administrator's email will be used as the 'To' in the outbound email. The goal is to later extend the flow to first check if there is an assigned Territory, and finding none, then use the Sales team - next post!
As for the email itself, the body part will show a list of the new leads that need attention.
Recurrence
Add a Recurrence component to establish the checking schedule. Unintuitively, one must set an Interval of 1 and a frequency of a week. Set the days of the week the trigger will start and the hour of the day for each day. For example, if the goal is to check for new Leads at the beginning and end of each weekday then ensure to select M-F and then the 8 and 17 for the hours.
Initialize Email Variables
One cannot initialize variables after the main block so it is necessary to declare any variables in the first main block. I would suggest that they should all be done together. I didn't for this Flow :( but would to fix it up. The variable that is declared in the second component will contain the email of the Sales Manager. The variable here is assigned a null string.
Build list of new Leads
A main component. This performs a ODATA query to get the new Leads. In this scenario, 'New Lead' means a Lead with a status code of 1 (status reason = New). From an out-of-the-box business process perpective, Leads move from New to Qualified. I added an Assigned step whereby the Sales Manager would assign a new Leads to a sales person triggering a new step. If I were to refine this further, I would include a Lead Source condition to only pull Leads created from the web channel (leadsource eq 9).
Initialize Leads List Variable
Here I initialize a string that will contain a list of all the new leads. A null string.
Loop through new lead list
This component - Apply to each - will loop through all new Leads in the list. One needs to get the output of the new lead list which is stored as a Value element of the Dynamics 365 connector.
It is worth pointing out that with recent billing changes that retrieving all Leads and then adding a condition to see which ones are New or not will cost more money then retrieving a smaller list from the start. I'll have to make another blog about the cost benefit here.
Within the Apply to Each component, I've added an Append to string variable action that retrieves the values of three fields and concatenates them together. Select any Lead fields as desired. One point. The end of the line is a 'br' code - press CNTRL and press Enter to insert this. Remember, the general goal is showing sufficient enough information to a Sales Manager to make a decision about what to do with a Lead. (Another extension to this Flow would be to add a button to the email so that the Sales Manager could assign it straight from the email; right now I'm assuming they are using the mobile app!)
Check condition
I added a check condition as I didn't want emails without any new leads to go out. It is important not to over email! However, there may be scenarios where this is desired - for example, when no new leads is an important data point for a sales manager. it also indicates that the system is working which may provide additional confidence. But again note that it would be best practice to minimize processing where possible to minimize flow costs.
The condition checks if any new lead information was found. If not, then it does nothing. If one or more new lead was found, then the flow transitions into getting the email address to send the list to.
Find the Sales Manager Email
Getting the Sales Manager Email required to first find the 'Sales' team record and then get the Administrator's email address as the email address is not stored on the team record. Fortunately, the Expand Query option allows one to join the tables together and return the appropriate record without having to perform a second search.
The component retrieves any Teams records with the name 'sales' (not perfect but effective enough). It retrieves all found records (only 1 should be returned). The 'administratorid' part of the Expand Query reflect the name of the lookup field on the Teams form that connects the Teams record to the User record (NOTE: documentation suggests to use the relationship name value - this doesn't work; use the schema name!). The remaining part of the Expand Query retrieves the first and last name and email address of the Administrator. (I only use the email in this flow).
Assign email to variable
Not as easy as it sounds! First get the list of 'sales' teams joined with the user entity. The output of the query is in JSON format which means that the query result needs to be parsed. To do this a sample of the schema to be parsed needs to be provided.
For example, I copied the following part that pertains to the Administrator's email (user entity).
{
"type": "object",
"properties": {
"@@odata.type": {
"type": "string"
},
"lastname": {
"type": "string"
},
"firstname": {
"type": "string"
},
"internalemailaddress": {
"type": "string"
},
"systemuserid": {
"type": "string"
}
}
}
Note: the Apply to each 2 'value' is the output of the Get Sales Team component. The Parse JSON 'content' reflects the current values of the current Sales record - remember there may be more than 1 since this is a list!
Set the Email
Since there is only one 'Sales' team record it is ok to have the Set Variable out of the Apply to each 2 loop. Not the best form. Thinking back, it would be good to extend the solution to check if one and only one 'sales' record was returned in the query. If there were zero or more than one then an email to the sysadmin would be in order.
The 'value' of the variable is assigned the parsed 'internalemailaddress' value which is the output of the Parse JSON component.
Send the email
Finally! Seems like a lot of work as most of these customizations become.
Here the 'To' value is assigned the Sales Manager's email address and the body of the email assigned the list of new leads.
