Workflow engine and server side validation

When a workflow uses server-side validation, interactions are validated before they are sent to the database and can therefore be returned immediately to the user if validation fails. This ensures that the workflow engine processes interactions that meet specific criteria only.

For example, an employee might submit a Safety Boot Request Form (an interaction) that uses server-side validation to determine whether the requested shoe size is available before the interaction is processed by the database and routed to the supervisor for approval. If the shoe size is unavailable, the Safety Boot Request Form is returned immediately to the employee for resubmittal and is not processed by the database—thereby saving processing time and improving system performance.

Validation actions

When creating workflows with server-side validation, developers do not have to rewrite workflow actions for them to be used within a validation branch. When constructing a workflow, you can designate specific actions at the beginning of the flow as validation actions. The workflow developer marks the actions appropriately to determine how far the chain of validation actions extends.

Validation nodes

Workflow developers can indicate if a validation fails by branching to a rejected node in the workflow. If validation fails, the API returns the interaction with an explanation message displayed to the user, providing options to return to the previous form or cancel completely.

Because multiple rejected nodes can be placed on any workflow, workflows can include separate rejected nodes with distinct messages indicating why specific validations failed. Alternatively, the validation node can return an exception status and display the corresponding message to the user.

Note: For an action to be used within the validation portion of a workflow, the action must not pause the workflow. Server-side validation pauses for actions that have the Person attribute set to true (checked). Nodes in the validation chain that require a pause and human interaction can be Employee, Role, or similar custom nodes. Form Studio prevents a flow from being saved if the validation chain contains pauses in the workflow. Aside from this requirement, actions in workflows using server-side validation function identically to standard Workflow Engine actions.

Shift Trade Eligibility workflow nodes

By default, the standard Shift Trade workflow uses the Shift Trade Eligibility node. The Shift Trade Eligibility node evaluates shift eligibility while processing the trade. In this default configuration, the submission proceeds to the database; if an eligibility check fails, the employee is notified of the failure reason through workmail.

To prevent eligibility checks from blocking shift trade processing and to allow chaining of custom validations, the Shift Trade Eligibility node can be replaced by two split nodes:

  • Validate Shift Trade Eligibility: Belongs to the validation chain and validates shift eligibility before the trade request is saved to the database. If an eligibility check fails, the employee immediately sees the failure reason on-screen in the Self-Service Portal, and no failure workmail is sent. Additional custom validation nodes, including Groovy script nodes, can be chained through this workflow.
  • Initiate Shift Trade: Saves the pending trade request and locks the shifts involved. This node runs only after the validation node passes, ensuring that no records are saved for trades that fail eligibility checks. The shift locks are automatically released once the request is accepted or rejected.