Recently, we’ve started building out our internal deployment of D365, called TapRoot. Being a new startup and knowing that recruiting would be very important as we start to think about growth, one of the functions we decided to include out of the gate was some very simple Applicant Tracking.
Our needs were pretty straightforward, we just needed a data model to support the tracking and status of Applicants within our pipeline. As I started designing/building out the module, everything was pretty painless. As you can see below, we have a custom entity (Applicant) which serves as an intersect, tying together Contact (Type = Applicant), School, Role, Source, Status, and some custom fields.
Once the core objects were built, we needed to do some gold-plating for things like:
- Business process flows
- Enabling for the App for Outlook
- Auto-naming of entities
The last bullet is where my issue surfaced. For several reasons, which I won’t go into for this post, I decided to use native workflow to auto-name my entities. Again, these workflows were extremely basic, so I did not foresee running into any issues in creating them – oops.
Once I started creating these workflows, I hit a snag when trying to auto-name my Applicant entity. I was able to create and save the workflow, but any time I tried to add an ‘Update Record’ step within the workflow, the classic editor would crash when loading the form definition, providing the following message:
As you can see, not a super helpful error message – so what now? As I usually do in scenarios like this, I took my issue to the broader D365 community. Most times when you run into challenges, you are not the first and the D365 community is great at sharing issues and more importantly their respective solutions. Unfortunately, this was one of the rare occasions where nothing was available.
My next step was to partake in some old school troubleshooting – much to my delight, after some quick Fiddler traces and collaboration with colleagues, I was able to identify the cause of my issue, as well as a workaround.
Issue
Most of us are well aware by now, the native Dynamics workflow editor has not been migrated to the PowerApps admin portal – you are forced to go through the ‘Classic Editor’ to build native workflows. Unfortunately, the ‘Classic Editor’ has some challenges with new feature functionality only available in the new Admin Portal. Specifically, in my case, I had a ‘File’ field type on my form to capture the Applicant’s physical resume – the native ‘Classic’ workflow editor is not able to render these fields, resulting in the above error message when the Classic Editor attempted to load the form definition (which makes sense).
Resolution
The resolution here was quite simple. By just following the below steps, I was able to get my workflow created and published:
- Edit the form definition, temporarily removing the ‘File’ field type from the form
- Publish customizations
- From the Classic editor, create, save and publish my new Auto-Name workflow
- Now that the ‘File’ field type is removed from the Form definition, it loads without issue
- Edit the form definition, adding the ‘File’ field type back to the form
- Published customizations
Once I followed the above steps, my issue was resolved and I was able to continue building out my solution.
While this is not necessarily an earth-shattering finding or super enlightening, the odds of someone else running across are probably pretty high, so hopefully this saves a few people a couple of hours.