Dynamics CRM workflow editor bug might be related to editable grids

The problem: While creating a workflow process in Dynamics 365 (CRM Online), the "Form Assistant" drop-down boxes (i.e., where you can select the "Operator" or dynamic values) were empty/blank.

What we tried: We tried these steps to troubleshoot the issue: 1) click into a variety of fields to see if the problem is related to specific types of fields (no, the options are blank for all field types), 2) clear browser cache, 3) try IE, Chrome and Edge, 4) determine whether the problem is happening for all entities.

Some clues: Regarding #4 above, the problem with the blank options when editing a workflow step occurred for some entity types but not all. So what was common between the entity forms where this bug occurred?

The fix: It turns out, at least for the CRM organization we're working with, that if there's an editable grid on the form, then the Form Assistant controls do not get populated. We removed the editable grid, saved, published and then tried editing the workflow step again. That resolve it: The expected operators, field choices, etc. are appearing in the workflow step edit page again.

This might be a coincidence, but this work-around is worth trying if you run into the same problem.

Prototype and fail early with cloud-based development

In these days of rapid and incremental software product releases, where development companies add features for our benefit but often before thoroughly testing them, it's crucial that we all approach projects in a prototyping mindset and find the bugs early rather than assuming that all released features are going to work as we progress through an application.

It used to be that when you bought a license to, for example, Microsoft SQL Server, you were confident that any problems you encountered were likely due to your own code.

These days, it's difficult to know whether a bug is due to something you're doing wrong or whether it's a "known issue" to the software manufacturer due to releasing functionality too quickly.

My latest example of this relates to Microsoft PowerApps. I created and finalized several screens and moved on to the last part of the project and that was to simply list records from a Common Data Service (CDS) entity that relate to a record selected on a previous screen. This is fully supported and Microsoft provides examples on how to do this.

Then I ran into this "known issue": "For some connectors, the connection to the data source is lost if you modify the Items property."

In my case, I selected the connection to the CDS entity for a data table and went to apply a filter and the data source disappeared. I thought that I was doing something wrong so I re-read the documentation on using filters and the best I could tell I was using the functionality the way it was designed.

Then I searched online some more and eventually ran into the issue.

I'll likely find a work-around to this bug, probably by storing the related data onto the main CDS entity itself.  But this is another reminder to myself, and hopefully to you as well, to approach application development with cloud-based platforms in a way where you prototype as much of the functionality first before spending a lot of time polishing various forms/screens so that you can switch gears on your design when you run into an issue like the one I described.

Checking for existence of record in Azure Logic Apps

I recently had the need to store data into an Microsoft Common Data Service (CDS) database, and using a Logic App seemed to fit the need in this case.

Project requirements:

- Run the integration (data copy) once per day
- Query Dynamics 365 (CRM) for Project records
- Insert or update into the Common Data Service database, to the Project entity

I'm probably missing something obvious, but that last step was more difficult to figure out than I thought. I created a "For each" to loop through the CRM records and then wanted to query the CDS entity to determine whether or not the record already exists. If the record exists, update it, if it doesn't exist, create it.

To query the CDS entity to determine whether the source CRM record exists, I used the CDS "Retrieve record" action. When running the Logic App, though, when it encountered the condition where a CDS record didn't exist the Logic App stopped processing and set the instance as "Failed".  Not finding a record really shouldn't be considered a failed job, but that's the way Logic Apps handles this condition.

The way Scribe Online handles this type of query is to set a property (e.g., RecordsMatched) to indicate whether or not the record exists. You can use the property's value in IF..THEN formulas to change the runtime processing path.

In Logic Apps, I couldn't find a simple way to set a condition based on whether or not it found the CDS record. The solution I came up with was to check the HTTP status of the query to the CDS. A response of 200 means that the record exists and a 404 means the record does not exist.

For the "IF" statement in the Logic App (after querying for the CDS record), I switched to "Code view" in the Logic Apps Designer and set the expression to the following:

"expression": "@not(equals(outputs('Attempt_to_retrieve_Project_CDS_record')['statusCode'], 200))",

Here's how that change looks in the Designer view:

From there, I added an action to insert the CDS record if it doesn't exist or update it if it does exist.

This solution was confusing because I couldn't find any examples or documentation from Microsoft on how to deal with this common scenario. I found an article on dealing with "exceptions" using the runAfter setting for an action, but checking for a record and not finding it really isn't an exception, it's a simple operation that should, in my opinion, be easier to handle in Logic Apps. Maybe it is and I just missed it. If so, please let me know.