Back to Blog

How to implement workflows in Microsoft Dynamics 365 for Finance and Operations without overlays

Post by |

Microsoft has introduced a new development concept in Dynamics 365 for Finance and Operations (D365FO) which allows extending the standard functionality without actually modifying the original code. Customisation using overlaying is similar to the customisation approach used in the previous Dynamics AX versions, and the aim of this blog is to present, from the development point of view, a workaround to implementing a new workflow type in D365FO, based on a standard table without overlays. The key element of the solution is a new table used to store the workflow related information. The method canSubmitToWorkflow() of the new table will be used to make the Submit button available in the UI instead of overlaying the standard table.

The new Application Object Tree (AOT) elements required:

  • A new table to store workflow related data
  • The workflow category
  • The workflow document (sometimes called the business document)
  • The workflow type

The development is split in several steps to make the process easier to follow, and I have used the standard customer table to create a customer request workflow type as an example.

Step 1: Create a new workflow category

The workflow category will bind the new customer workflow type to the AR module and will add the related workflow entry into the module list page.

Step 2: Create a new enum to trace the workflow approval status in UI

The tracking information will be available in the document details form. A workflow status of Approved, Return or Denied will mark the related customer as Open, On hold or Closed.

Step 3: Create a new table to store the workflow related information

The following customisations are required for the new table:

  • Keep the new customer workflow table and the standard CustTable synchronised. Use chain of command for the insert() method of the standard table, set delete actions, and restrict the delete operation for customers with workflow activity in progress.
  • Only two types of join can be used to link the new customer workflow table to the standard customer table: inner and outer join. Consider the existing customers in database and create a script to populate workflow data for existing customers when inner join type is preferred.
  • All fields in the new table should be read only: we use them for tracking purposes in the UI but only the workflow should update these values.
  • Override the table method canSubmitToWorkflow() and add the logic to show or hide the submit button in the UI.
  • Create a static method updateWorkflowState() to be called by the workflow event handlers when the status must be updated.

Step 4: Create the workflow document (query)

The workflow document is the information that will go through an approval process, in our case a customer record.

Two application elements compose a workflow document in the AOT:

  • The document query – created manually by the developer
  • The document class – generated by the workflow type wizard

The document query is used to expose customer fields in the workflow editor expression builder. It is a best practice to set the Fields dynamic property to No and expose the necessary information only in workflow designer.

Step 5: Create and update the workflow type block

The Workflow Type wizard will have as input the workflow category, the document query and the CustTable menu item pointing to the document details form.

Document class

The document class is one of the elements generated by the wizard. It can expose calculated fields (parm methods) used in the workflow designer to make conditional decisions. These methods are good candidates for unit testing as they do not involve user interaction.

Event handler class

From the development point of view, we control at the workflow type level whether the workflow is started, cancelled, or completed.

The workflow engine knows internally the status of the workflow. The purpose of the status field updated by this event handler class is to allow the progress to be displayed in the UI and to act on a particular workflow event.

Submit manager class

The submit manager class contains the logic to be executed once a work item is submitted (display the submit dialog, get the notes text, activate the workflow type and change the status to submitted). Make sure the workflow controls are updated after the submit operation to avoid resubmitting the same record multiple times.

Step 6: Enable the workflow on the CustTable form

At this step we enable in code the workflow for the customer table using the new form data source.

Key Benefit

The main benefit of this approach is to keep the workflow code and data isolated. Prior to D365FO platform update 20, this was the only way of adding workflow functionality based on a standard table without overlaying the canSubmitToWorkflow() method.

D365FO platform update 20 includes extensibility enhancements that permit Chain of Command for form methods, so canSubmitToWorkflow() method is available at the form level. Also, the properties WorkflowEnabled, WorkflowDataSource and WorkflowType can be set directly at the data source level using form extensions.

Further reading

Extending Microsoft Dynamics 365 for Operations Cookbook, Simon Buxton

Dynamics AX 2012 Blueprints: Developing a Product Approval Workflow, Murray Fife

Dynamics AX Workflow Wanderings: Hints and Tips for Dynamics AX Workflow, Jonathan Halland

About the Author:

Viorel Morosanu has been a Software Engineer for LexisNexis Enterprise Solutions for three years. His focus is the LexisOne ERP solution built on Microsoft Dynamics 365 for Finance and Operations (FO). Previous to this he worked on the Dynamics AX 2012 version of LexisOne. Viorel has more than eight years’ experience with Microsoft Dynamics and has been involved in over 10 customers implementations for Microsoft Dynamics AX versions 4.0, 2009, 2012 and Dynamics 365FO.

| See all our contributors
Back to Blog