The trick, as the payment model is per run, is to trigger it per Survey Response, and not Question Response. Hence the logic has to loop through all the question responses.
The way you create a filter in Flow for the query is to use Odata filters. However, I found that these were a casing nightmare, which those of you who have worked with more, probably also have noticed.
After troubleshooting a lot with different queries in the browser I finally found that the following actually worked. Note that you will have t change the guid to your own.
https://dev-dtn.api.crm4.dynamics.com/api/data/v9.1/msdyn_questionresponses?$select=msdyn_name,msdyn_SurveyResponseId&$filter=msdyn_SurveyResponseId/msdyn_surveyresponseid%20eq%20460279E7-2AF2-E811-A97F-000D3AB0C08C
The tricky part, as you can see, is that the first part of the lookup attribute, is defined in camel-case and the one in the related entity (Survey Response) in lower case.
The part you need in the Flow is the last part, but it is useful to test it directly in the browser to make sure you get the syntax correct.
 |
| Its the filter part of the query that you are to enter into the "Filter query" field, and make sure to make it dynamic. :) |
And this is how it looks in Dynamics 365 CE if you check out the fields. I like to look at them in the list view as I can see the schema name there, which isn't visible in the Form.
 |
| msdyn_SurveyResponseId Lookup from the Question Response Entity. As you can see it seems to be using the Schema name above. |
 |
| This is the primary field Survey Response. Do note the subtle difference between the fields, that Id is spellt with a capital "I" in the Schema name. Based on the information above, it hence seems to be using "Name" to indicate the field. |
Hence based on the above, the supposition would be that the syntax is <Schemaname of the lookup>/<name of field in target entity>
I then did a query to business Unit and I was very surprised to find that it was rather inconsistent and looked like this:
https://dev-dtn.api.crm4.dynamics.com/api/data/v9.1/businessunits?$select=cntso_organizationbaseurl&$filter=parentbusinessunitid/businessunitid%20eq%20null
with just the query that would be
parentbusinessunitid/businessunitid eq null
Let's have a look at the fields in Dynamics:
 |
| The Parent Business Unit Lookup in Business Unit (Self Referential). Note that the Schema name is Pascal Case. |
 |
| key field, businessunitid in Business Unit |
And as you can see, if we were to follow the syntax set by the example above, this should be:
ParentBusinessUnitId/businessunitid
However, that didn't seem to work, and as a pragmatist, I have to conclude, somewhat sad, that this doesn't seem to be very consistent.
My recommendation is hence when working with this:
- Do not take any casing for granted
- <Schemaname of the lookup>/<name of field in target entity> is probably correct for most custom fields/entities.
- Many older entities and fields, like the businessunit shown above, has been there since CRM 1.0 or at least 3.0, if I remember correctly and hence the syntax might be different.
- Test your queries directly in the browser like I have shown above.
Good luck with your Flows.
And if you know Swedish, make sure you check out my colleague Martin Burmans article on Flow as well. Not sure how well it turns out in translation. https://www.crmkonsulterna.se/flow-i-medvind/
Gustaf Westerlund
MVP, Founder and Principal Consultant at CRM-konsulterna AB
www.crmkonsulterna.se
