Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Workflow variables in Joget are key data elements that are essential for the overall operation and flow of a process. Unlike data specific to individual forms or activities, workflow variables have a broader scope and are used throughout the entire process. 

Distinction

...

Between Normal Data and Workflow Variables

For example, consider a Leave Application process where form data like application date, leave duration, and reason are specific to each application. They are used for record-keeping and informing supervisors about the leave request but do not control the workflow.

Workflow variables, on the other hand, are elements that carry significant weight in determining the flow of the process. In the Leave Application process, a good example of a workflow variable could be "supervisorApproval". This variable might store a value like "approvedApproved" or "rejectedRejected". The value of this variable is used to decide the next steps in the workflow. For example, if "supervisorApproval" is "approved", the process might move to the HR department for final processing. This variable becomes crucial when a supervisor's decision (accept or reject) alters the course of the workflow, triggering different activities or decisions.

Here is a screenshot from a sample app showing a process builder and workflow variable initialization.

...

Influence on Process Flow: Workflow variables are often used to control process routing, conditions, and decision points within a workflow. Their values can determine which path a process takes, or which activities are triggered next. 

Info
titleExampleInfo

In Joget, a form field and a workflow variable, even if named similarly (e.g., both called "status"), are distinct entities. A form field is specific to a form and is used to capture user input, while a workflow variable is a broader process-level variable that can influence and guide the workflow's progression and routes taken. So in this case, the 'status' variable is also stored in different database tables.

Storage: Stored on a database table separate from the form data. These variables are stored in the "shkactivitydata" database table and are not to be tampered with for reasons mentioned below in the section Storage mechanisms for form data variables and workflow variables.

Key Concepts

Hash Variables

...

It is recommended to read this article to have a clearer understanding of what hash variables are.

Populate Data

...

Dynamically

For functionalities like populating an email body, both form data (accessed via # form#form.table.status #status#) and workflow variables (# variable#variable.status #status#) can be utilized, offering flexibility in how data is referenced within the workflow.

Please do keep in mind that it is important to not confuse the form data with workflow variables. As explained before, they are separate entities but both entities can be used as hash variables for use inside, for example, an email body.

Scope of Use

Please note that every hash variable has its scope of use. This dictates where the hash variable can be used. Workflow variable hash variable(#variable.variableName#),  can only be used by elements within and part of a Process.

Additionally, these values are being parsed on the server side, not the client side. If there is a need to parse it, you will need to use workflowutil.processVariable method to do so.

Update Mechanisms

Form Data Update Tool: This built-in tool is used to update values directly in the database. To use this go to Process Builder>Tools> Mapping> Builder > Tools > Mapping > Select Update Form Data> Data > Update Fields.

The changes made using this tool affect the data stored in form fields. This tool ensures that any changes or entries made to form fields are correctly reflected in the database, without needing manual input, directly within the workflow process.

Figure 2: Form Data Update Tool in Process Builder

Workflow Variable Update Tool: Available at the marketplace, the Workflow Variable Update Tool updates the value of workflow variables. To use this go to Process Builder>Tools> Mapping> Builder > Tools > Mapping > Select Workflow Variable Update Tool> Tool > Workflow Variable Mapping.

...

While workflow variables are essential for process routing, other elements like form data and hash variables can also be used for similar purposes. For example, using a form hash variable in a transition condition e.g., ((# form#form.Approval_Form.status # status# === "Approved")) is a viable alternative to check for conditions and make decisions in the process workflow. 

Both form hash and workflow hash will work. Apart from routing, a workflow hash can also be used within the application for dynamic data referencing, such as in custom scripts or email bodies, where they can be called upon using syntax like # variable#variable.status #status#.

Figure 4: Making a routing decision using a Workflow Variable in Process Builder


Figure 5: Making the same routing decision using a Form Hash Variable in Process Builder

For this example, this status field is present in a form named Approval Form. In the above figureFigure 5, we are simply checking if the value in this form is "Approved" or other than approved ("Rejected"), and then we proceed to route to the correct decision.

Figure 6: Status Field options

...

Figure 7: Viewing a Completed Activity Instance

In this view, one can see the state and statistical data of a particular completed activity instance.

Choosing the Right Tool

The decision to use workflow variables, form data, or hash variables depends on the specific needs of the process. For simpler decision-making where an audit trail is not critical, form data or hash variables might suffice. However, for complex processes where tracking the history of decisions is important, workflow variables become indispensable.

...

As a best practice, it's recommended to map workflow variables to form fields. This mapping ensures the values of workflow variables are 'copied' to corresponding form fields at each activity, making them visible and accessible for later viewing in forms and datalists. This approach avoids the direct querying of the large "shkactivitydata" table, thereby optimizing performance.