*** NOTE: ALL INFORMATION IS ACCURATE AT DATE OF PUBLISHING ***
In a recent survey we looked at Using Parameters To Pass Forms Pro Survey Context. Within that post, a Lead record was created when they filled out a survey embedded in to a website. One thing we didn’t do within that was to check and see if the Lead record already existed within the related Dynamics 365 Customer Engagement (or CDS) environment. In this post we will look at how to achieve that.
If you are not comfortable with Microsoft Flow and you are interested in using Microsoft Forms Pro, it might be time to change that. You can do so much to extend the functionality by combining the two. We are going to create a new Flow that will end up looking like this.
It might looks a little overwhelming at first if you aren’t used to it. We will break each step down together. First, go to Microsoft Flow and click to create a new Flow. Select the Automated – from blank option.
Give your Flow a name, and search for the Common Data Service triggers. Select the ‘When a record is created’ option and then click the Create button at the bottom.
You can rename the trigger step, so here we see the ‘New Survey Response’ trigger. We pick the environment, entity of Survey Responses, and the scope of Organisation.
Now add the first action step. Look for Microsoft Forms, not the Forms Pro connector. Then choose the Get response details action.
Pick the Forms Pro survey from the Form Id list. We need to get the response id of the new survey response record. To do this, we need to convert the response id to an integer value. For this, we click in the Response id field in the action, then click on the Expression tab on the right, and paste in the following, then click OK.
Check out this blog referenced at the top of this page which shows how to embed your survey in to a web page. If you are not embedding your survey, you can ignore the next steps that are related to the Parse JSON action. Now we need to get the parameter we added to the survey embed code that tells which page, or product the responder was on when they submitted the survey. To do this, we are going to use the Parse JSON action. In the Content field, select the Context Data from the initial trigger step of your flow.
Click on the link at the bottom of the Schema field – ‘use sample payload to generate schema’.
Past the following in to the window that opens, making sure you use the exact name of the parameter you added to the survey in Forms Pro. Where it says “Product Name” this can say anything. It will be replaced by the ACTUAL product name you added to the website.
Once you have clicked Done, you will see the Schema formatted correctly. Each time the flow runs, it will parse the context data and the ProductPage value.
Next we are going to use the List Records action from the Common Data Service connector. Set the environment and entity. Then in the advanced options set your ODATA query filter. For this, I want to check that the emailaddress1 field equals the value in the Email field on the survey from Forms Pro. If you are using other mechanisms for duplicate detection checking, ideally you could only have one Lead that matches this.
Next use the Condition control. This part is thanks to the wonderful Bruce Sithole. After searching for a while on a way to do this using Microsoft Flow, I came across a blog post of his. It didn’t quite do what I wanted, so contacted him and he provided the right expression to check and see if a Lead already existed in CDS. Check out his blog here for a detailed description on what the expression is doing. Add the following in to the Expression for the Condition. Where it shows List_Lead, this must be the name of your List Records setp, so if you have renamed it, be sure to update the expression accordingly.
Set the condition to ‘is equal to’ and the value to true. Be sure to use the Expression when adding true, don’t just type in the word true directly in to the box.
OK, so now you will have two sides to the condition, Yes if it’s true, and No if it’s false. True being the Lead already exists. So for the Yes side we need an update record action from the CDS connector. Here is where we link to Survey Response to the existing Lead. Use the Activity id from the Survey Response as the record identifier.
Set the regarding field as the Lead id from the List Lead step. Set the Regarding Type as leads.
As soon as you set the regarding you will notice that an Apply to each appears at the top of that section. This is necessary, and runs through as many Leads that are found, which in this case should just be 1.
Set the Respondent and the Respondent email address fields using the values from the List lead step.
Finally, set the Subject from the Parse JSON step to include the Product Page. Ignore this if you have not embedded your survey in to a Web Page.
Now let’s look at the No or False action. If it’s false, it means the Lead wasn’t found based on the email address provided. So we need to use the Create record action from the CDS Connector and create a New Lead. Use the values from the survey to populate the First & Last Name, and Email Address. You can use the Parse JSON step and populate the topic based on the web page if you have embedded the survey. Otherwise, fill the topic with something relevant to your scenario.
Once you have created the lead, you need a similar step to the Yes side where you can link the survey to the New Lead, rather than the one from the List Lead action.
Now when the survey is submitted, we see the Flow below has found the person already in CDS based on their email address, and it’s linked the Survey Response to that record.
We can see two different survey responses linked to Paul Smith’s record. Awesome! No duplicate leads here!
And finally we have a submission from an email address not already in CDS, so it created a new lead and then linked the survey response accordingly. So, thanks again to Bruce Sithole for the much needed assistance for the expression we needed to check against the email. You are a lifesaver! ????
Want to just watch how to do this? Check out the video below:
Check out the latest post:
Checking User Access To Model-driven Apps (D365 CE)
This is just 1 of 338 articles. You can browse through all of them by going to the main blog page, or navigate through different categories to find more content you are interested in. You can also subscribe and get new blog posts emailed to you directly.