Back to Blog

Using State Machines in Microsoft Dynamics 365 for Finance and Operations

Post by |

In this blog article we are going to take a look at state machines. State machines are a new concept in Microsoft Dynamics 365 for Finance and Operations (D365FO) and they are a really great feature that enables workflow events to be bound to state transitions on the underlying entity's state machine. This binding enables business logic to be centralized within the state machine and also enables the workflow system to be a declarative consumer of that state machine. The workflow metadata can reference a state transition that is performed when a specific workflow event occurs. Therefore, you can do state transitions within a workflow without writing any additional code, as opposed to AX2012 version where the control of status fields was handcrafted in code, which could be often hard to read as there was no obvious pattern to follow.

There is a restriction though: there must be one initial state and one final state. When we are at the final state there is no going back. For example, if we take the sales order status, we have two final states: Invoiced and Cancelled. There is another reason why we wouldn't use a state machine on this type of status: the sales order status is a reflection of an actual order state, it is system controlled. State machines are designed to enforced status change logic when the state is asserted by a user.

So, let’s see how we can implement this in D365FO.

What is a state machine?

The state machine is an abstract machine that can be in exactly one of a finite number of states at any given time.

State machines allow us to define, in metadata, how the status transitions from an initial state to its final state. These rules are then enforced by code that the state machine will generate.

Let’s take a look at an example of how we could use the state machines for a customer approval process.

Creating a state machine

Business Requirement

In our workflow there is a requirement to perform a credit check before a customer can be submitted for approval. This is a very common requirement in legal firms. It represents the first step in our workflow business process, as you can see on the picture down below:

Workflow editor

The Credit check block on the workflow editor diagram is a manual task and it’s created within Visual Studio by adding a new Workflow task item to your project and running the manual task wizard, found under the Business Process and Workflow category. This will generate the block for you and make it available in the workflow editor.

Adding a new workflow task

Prerequisite

For our state machine example, we have created a table called AXUGCustTable. This table is an extension of the CustTable and it holds workflow related information.

The table has a status field with an initial and final status, such as the CustCreditCheck field which represents the state of the credit check manual task.

AXUGCustTable

The CustCreditCheck field is represented by the AXUGCustCreditCheck base enumeration which contains the following elements:

How to do it

In order to create a new state machine we will expand and right-click on the State Machines node in the AXUGCustTable and add a new state machine. It should look something like this:

Adding a new state machine to the AXUGCustTable

After this step we need to define each state for the AXUGCustCreditCheck base enumeration and we then need to define the transition rules for the state machine. Make sure you provide labels and descriptions for each element. The result should look like the following screenshot:

State machine and its transition rules

Please note, the CreditCheckNotStarted represents the Initial state and the CreditCheckClosed represents the Final state. All the other enumerations are Intermediate. You can specify this by setting the State Kind property on each state, just like in the screenshot below.

Initial state

The final step is to right-click on the CustomerCreditCheckStateMachine node and click Generate. This generates the code that will be used to control the credit check process progression.

Further Reading

Extending Microsoft Dynamics 365 for Operations Cookbook, Simon Buxton

About the Author:


Krisztina Lutean is a Software Engineer for LexisNexis working on the Dynamics 365 for Finance and Operations version of the LexisOne ERP solution. She is based at the LexisNexis office in Leeds, UK, where she has been working on Dynamics 365 for Finance and Operations for the last two years. Prior to this she was working on the Dynamics AX 2012 version of LexisOne. She has five years’ experience working with Microsoft Dynamics AX.

| See all our contributors
Back to Blog