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.
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:
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.
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!)
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.
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.
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.
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.