Workflow via Code – Part 4

In the previous parts of this series, we setup the shell of a basic workflow, added actions and transitions, hid the legacy Hold checkbox from the screen, and used transitions to change the current state of the document. In this part, we will look at conditions.

Perhaps we need something to work “only when”… that’s a condition. First we will define conditions in the graph extension, and then we will use them in the workflow screen configuration.

It is worth noting before we jump in that actions for Complete and Reopen have been added to facilitate a simple examples of conditions and complete the basic functionality for this screen. These were added exactly like the other actions defined in the workflow, and the code can be seen in the gist at the end of this post.

Defining Conditions

Before jumping into defining the conditions, let’s take a look back at a line of code from Part 1 which was noted as being a convenient time to included for later. Defining conditions relies on:

View this gist on GitHub

This line of code enables us to simply type Condition in line 2 of the following code which defines 2 basic conditions for our Work Order.

View this gist on GitHub

Line 2 above allows us to make the BQL calls in lines 7 and 9 referenced by the conditions auto-named in lines 6 and 8, respectively. The addition of this code allows us to simply refer to a condition by name instead of redefining the condition over and over again, which makes the code reusable within our workflow but also much more readable.

Using the Condition

Now for some of the most complicated code you will ever see. It’s so amazingly complex, that I hope you can grasp it! (And I hope you get the humor here!)

View this gist on GitHub

Yeh, that’s it. Just add a .when(condition) to your workflow definition. For the inverse of a condition, you can use .when(!condition) as well.

So, when can we use conditions? If you think about it, a condition only applies when you are doing something. Do you recall what part of the workflow “does work”? That’s right, it’s the transition where we flip the document status and may do other field assignments. Conditions are applied to transitions to make sure they happen “only when” the condition(s) are met.

So let’s see a condition in action on a transition! Conditions have been applied to lines 8 and 26.

View this gist on GitHub

On line 8, we have applied the condition to only initialize the status of the document to Hold WHEN the hold field is true, as per how the condition was defined. On line 26, the state of the document will change from Open to Complete on clicking of the Complete action only WHEN the Work Order has a Scheduled Date.

Conditions to Disable or Hide Actions

Conditions also may be used to disable or hide an action. The extra code is just as “complicated” as with transitions, although the modifiers have a little more specific names. In the following gist, notice the addition of .IsHiddenWhen (line 11) to the predefined action and the addition of .IsDisabledWhen (line 21) on the workflow defined action. Both of these modifiers can be used on either type of action, but where the modifiers is added depends on whether the action is predefined or workflow created.

View this gist on GitHub

Note: Previously, we had defined the workflow defined actions BEFORE the conditions. However, when adding a condition to the workflow defined action, Visual Studio informed me that I cannot use a condition before it was defined. You will see in the full code below that the definition of conditions has been moved before the definition of workflow defined actions.

That’s it. It’s that easy to add a condition. At this point, we can put the Open Work Order back on Hold or Schedule it. If we try to Complete it, the transition does not complete unless the Scheduled Date is entered.

The complete code at this point is shown in the following gist.

View this gist on GitHub


Our basic workflow is reasonably functional now. We have created a basic shell for a simple workflow, added actions on the menu into categories of the drop-down menu, assigned actions to various document states, updated field values when actions are clicked, and setup conditions to restrict when certain transitions can execute. While there are more elements to explore, such as adding .WithHandlers, and expanding the workflow to be far more complex, this completes the four part series to get you started. I hope that this was presented in a way to help you easily understand the basics, step by step, to create your own basic workflow.

Happy Coding!

Leave a Reply