Exit Customer Voice Survey Respondent From Journey When Using Other Regarding Records

One of the cool things we can do with triggers is generate custom invitation links for a Customer Voice survey and put someone in a Journey to send them an email with a link to complete that survey. That’s a pretty common approach, and one I’ve implemented many times. What is a little less common is taking someone out of the Journey if they have completed the survey. That way you can send a reminder to anyone who hasn’t already shared their feedback. This post came out of the realisation that the out of the box trigger, OR a Dataverse trigger won’t do the job for all occasions to exit customer voice survey respondents. I’ll explain why and then share how to work around this.

First let’s look at why a Dataverse trigger or the out of the box trigger won’t work. When using the create an invitation action from the Customer Voice trigger, it’s important to understand the two fields pointed out below. Purple is the Regarding field. Think of any activity in Dynamics 365 and the Regarding field links that activity to another record. You could link to a Contact, Account, Case, Opportunity, Custom Table etc. We can use the Regarding field below to link the Survey Invitation to a record, in the example below it is a Case (incident being the database name). Note that the same regarding link is used on the subsequent Survey Response that comes back in to D365. The Regarding can be an entity of your choosing, but the Green arrow that points to the Recipient details must ALWAYS be a Contact or Lead. Also random side note, this is the only place in Power Automate I have seen entity and entityid referenced in this way. Weird right?

Ok, so now you have seen it set in a create an invitation step in Power Automate, this is how it correlates back on the Survey Invitation and related Survey Response. The Purple/Regarding is linked to a Case, and the Survey Invitation shows the Contact in the To field, and Survey Response shows it in the From field. The Name and Email Address from the record are added to the Respondent and Invitation email address fields. Not to get too in to it, but it’s all about how activities work using an Activity Party with a specific Participation Type. It’s not fun, but we can still use the approach of linking our survey responses to a different Entity, so let’s move on from this messy part.

Last part before we move on to the fix. If you try and create a new Dataverse trigger to run on the Customer Voice survey response table, you will see that it only maps back to the Contact or Lead via the Regarding field.

Right, on to our new trigger that we can then use in our Journey to take someone out of it when they fill out the survey response and are the respondent not the regarding. Create a very simple trigger and add the Contact (or Lead if that is what you are using for the Survey respondent) and an Entity Reference attribute and select the same table that you are linking your survey invitations to using Power Automate and the Customer Voice connector. Save and Publish your trigger.

Now move on to Power Automate to create your flow. It will fire using the Dataverse connector and when a Customer Voice survey response record is added.

This step will be different depending on how unique your use cases are, but for this, I only want to fire the trigger if the regarding field contains a Case record. Again, this table is called incident in the database. I can use the Regarding Object Type to check and see if it is equal to the table name. Always use the plural, which is why I have incidents. If the response is no, then nothing needs to happen, so the No branch of this condition will be left empty.

Moving on to the Yes branch of the condition, I can get everything I need from the Case record, so I just use the Get a row by ID step on the Cases table, and use the Regarding Object Value from the initial trigger. You can use the advanced options to only return the values you need to make it more efficient. In my case I just want the GUID for the Contact that needs to go through the Journey.

You should then of course be able to get the Contact ID from the Case record (or whatever your Regarding table is). However, if you really want to get specific and ONLY get the record that is in the From field on the Survey Response… this is where you can go in to the Activity Party table I mentioned previously. Again, only do it this way if you think you can’t get the right Contact via the step above (although I can’t think of a reason why not), otherwise ignore this part. You will do a list rows step for the Activity Party table, and use this in the Filter rows step.

_activityid_value eq @{triggerBody()?['activityid']} and participationtypemask eq 1

Again, only do this step if you want to go via the Activity Party table, otherwise ignore and go to the step below. Use this expression for the Signal user Auth ID and Profile ID. This is giving you the Contact ID from the Survey Response via the Activity Party table.

first(outputs('List_rows')?['body/value'])?['_partyid_value']

We now need a Compose step to create the information we will push across to D365 to fire our new trigger. Amey Holden wrote a brilliant post on how to do this that you can read here, no point in me recreating the whole thing. So check it out and come back.

Again, the post from Amey above will also explain this final step which starts the trigger and pushes all of the information in the step above back in to D365. It finds any Journey using the trigger (either to start it or exit from it) and does what it needs to do for the related Contact or Lead.

Once you have the trigger and flow sorted, the last thing to do is use it in a Journey. Below we can see I have a trigger being used at the start called Case Closure Survey which generates the initial invitation for the survey related to the case. This information is then used in the Case Closure Survey Email. We then wait 1 week and send out the email (or slightly modified version) again. What is important is the Exit tab of the Journey where we are using our new trigger as an alternate exit. A great reason for us sending through the Entity reference of the case is so you can also add in conditions to filter and only exist someone if fields or related records on the case match specific criteria. Leaving it blank means a Contact will exit when they fill out a survey related to any case of any type/subject/priority.

Once your Journey is live and people are running through it, you will be able to click on the Wait tile and see the number of people who exited, and also the reason why. Here we can see that the Exit Event is what caused them to be taken out of the Journey. So keep using the Regarding field for other things and linking those invitations and responses to different records, but know you can still remove your audience members from the Journey when they complete the survey,

Original Post http://meganvwalker.com/exit-customer-voice-survey-respondent-journey/