In Questetra BPM Suite, you can check values by setting conditions such as [Required] or allowable value ranges for each Data Item. In this article, we refer to this as “Data Item Value Validation” (hereinafter, Value Validation). If a Data Item configured as [Editable] in a Step retains a value that does not satisfy these conditions, the Operator cannot complete the Step. Additionally, you can configure initial values that pre-populate Data Items when a Case is started.
In this article, using an Expense Reimbursement App as an example, we will explain what to set for Value Validation and initial values, and when each takes effect. For basic operations regarding Data Item settings screens, refer to Chapter 6: Working with Data in Various Formats in the First-Time Workflow App Design guide.
Workflow App Used in This Article
This is an App where employees apply for expenses, their manager approves the request, and members of the Accounting Department make the bank transfer. Steps progress in the following order: Application (Starting Step), Approval, and Payment Processing.
The Data Items and their configurations for each Step are as follows:
| Data Item | Data Type | Application | Approval | Payment Processing |
|---|---|---|---|---|
| Applicant (q_applicant) | User | [Editable] | [Only Display] | [Only Display] |
| Date of Use (q_use_date) | Date | [Editable] | [Only Display] | [Only Display] |
| Amount (q_amount) | Numeric | [Editable] | [Only Display] | [Only Display] |
| Receipt (q_receipt) | File | [Editable] | [Only Display] | [Only Display] |
| Project Code (q_project_code) | String (Single line) | [Editable] | [Only Display] | [Only Display] |
| Scheduled Payment Date (q_payment_due) | Date | [Only Display] | [Only Display] | [Editable] |
| Transfer Date (q_paid_date) | Date | [Not Displayed] | [Not Displayed] | [Editable] |
The Value Validation and initial values set for each Data Item are as follows. The meaning of each setting will be explained in subsequent sections.
| Data Item | Value Validation | Initial Value |
|---|---|---|
| Applicant | [Required] | Case Start User |
| Date of Use | [Required] | None |
| Amount | [Required], Minimum value 1, Decimal places 0 | None |
| Receipt | [Required] | None (Cannot be set) |
| Project Code | Regular expression to satisfy ^[A-Z]{2}-[0-9]{4}$ | None |
| Scheduled Payment Date | None | End of the month following the Case start date |
| Transfer Date | [Required] | None |
Types of Value Validation
In addition to [Required], the following Value Validation options can be configured for each Data Type:
| Data Type | Configurable Value Validation |
|---|---|
| String-type (Single line / Multiple lines / Markdown) | Minimum characters, Maximum characters, Regular expression to satisfy |
| Numeric-type | Minimum value, Maximum value, Number of decimal places |
| Select-type (Checkbox) | Minimum selections, Maximum selections |
| Date-type / Date-Time-type | Minimum value, Maximum value |
| File-type | Minimum attached files, Maximum attached files, Maximum total file size (MB), Prohibit duplicate file names |
| Table-type | Minimum rows, Maximum rows (Value Validation per column can also be set) |
For User-type, Organization-type, and Select-types other than Checkboxes, the only configurable Value Validation is [Required]. For Discussion-type and Guide Panel-type, Value Validation including [Required] cannot be set.
Value Validation options per Data Type and system limits that apply even when Value Validation is not set are summarized in R2051: Value Checks and System Limits for Data Items.
In the Expense Reimbursement App, “Amount” is configured with a minimum value of 1 and 0 decimal places to prevent entering values of 0 or less as well as decimals. “Project Code” is configured with a regular expression that accepts only a format consisting of 2 uppercase letters, a hyphen, and 4 digits (e.g., AB-1234). For regular expression syntax, refer to R2060: Regular Expressions for Value Checks of String-type Data Items.
Timing and Scope of Value Validation
Value Validation occurs when a Case Operator attempts to complete a Step, as well as when saving via [Save and Quit]. If a value does not satisfy the conditions, a message asking the Operator to re-enter the value is displayed, preventing both the completion of the Step and saving the data. However, [Save and Quit] does not perform checks on [Required] items, allowing Users to save even if empty Data Items remain. Conditions such as regular expressions and maximum character counts are checked even during [Save and Quit].
Only Data Items set to [Editable] in the current Step are checked. Data Items set to [Only Display] or [Not Displayed] are not checked. While “Transfer Date” is [Required], it is [Not Displayed] in “Application” and “Approval”, so applying employees and managers can complete those Steps with “Transfer Date” left blank. Input for “Transfer Date” is prompted only in “Payment Processing”, where it is set to [Editable].
Value Validation settings are uniform across all Steps and cannot be changed on a per-Step basis. If you want to prompt input only in a specific Step, set that Data Item to [Editable] only in that Step, as done with “Transfer Date”. If set to [Editable] across multiple Steps, Value Validation will occur in all of those Steps. For details, refer to the FAQ Can Data Items be set as “Required” only at Specific Steps?.
When a Data Item is empty, only [Required] is checked. Because “Project Code” is not [Required], leaving it blank bypasses regular expression checks, allowing “Application” to be completed. Similarly, setting only minimum values or minimum character counts allows the Step to be completed while empty. To prevent completion while empty, configure [Required] alongside those settings.
Value Validation also occurs when automated Steps overwrite Data Item values. If an automated Step such as [Update Data] attempts to write a value that does not satisfy conditions, an error occurs in that Step. [Update Data] features a setting called [Allow clearing values of required Data Items]; enabling this allows clearing [Required] Data Items to empty values.
Configuring Initial Values
An initial value is a value set in a Data Item at the start of a Case. In Steps where a Data Item with an initial value is set to [Editable], the Operator can either use the initial value as-is or overwrite it.
Initial values are well-suited for Data Items that hold identical values in most Cases or Data Items that receive values determined by business rules. In the Expense Reimbursement App, “Scheduled Payment Date” falls under the latter. If you simply want to show an input example, use [Placeholder]. Setting an example as an initial value causes that example to remain as the actual value if the Operator completes the Step without modifying it. For details on [Placeholder], refer to Design a User-Friendly Input Form.
Initial values can be fixed values decided when configuring the App, or values determined at the start of a Case. Values determined at the start of a Case are derived from Case or App attributes (such as Case ID, Case Sequence Number, Case Start Date and Time, Case Start User, Case Start Organization, App ID, App Name, etc.). Only these Case/App attributes can be referenced; values of other Data Items cannot be referenced. Formats per Data Type are summarized in R2052: Initial Value Formats for Data Items.
Both initial values set in the Expense Reimbursement App are values determined at the start of a Case. The initial value for “Applicant” specifies Case Start User. When an employee starts a Case, that employee is set as the “Applicant”. For “Scheduled Payment Date”, the following SpEL expression is configured to calculate the end of the month following the Case start date:
processInstanceStartDatetime.addMonths(1).getLastTimeInMonth()processInstanceStartDatetime represents the Case Start Date and Time. When writing expressions for initial values of Date-types, write the SpEL expression directly without wrapping it in #{ } (whereas String-types wrap expressions in #{ }).
Because “Scheduled Payment Date” is set to [Only Display] in “Application”, applying employees can verify the value but cannot edit it. In “Payment Processing”, it is [Editable], allowing Accounting Department members to modify it to align with actual payment schedules.
Initial values cannot be set for File-type, Discussion-type, Table-type, or Guide Panel-type Data Items. In the Expense Reimbursement App, “Receipt” is a File-type Data Item, so no initial value is set. Furthermore, configuring [Expression] (a setting that automatically calculates and populates results) on Numeric-type Data Items disables configuring initial values, [Required], minimum values, and maximum values. For Select-type Data Items, initial values cannot be set if [String-type Data Item] is specified for [Type of data source].
When Initial Values Are Not Set
Even if configured, initial values will not be set in the following scenarios:
- When initial value is Case Start User: In automatically started Cases, no user started the Case, so it is not set. *1
- When initial value is Case Start Organization: When the User who started the Case can process the Start Step under multiple affiliated Organization roles, it is not set (positions do not affect the determination of whether processing can occur under multiple roles). *2
- When receiving values externally at Case start: Data Items that receive values via Message Start Events or similar will be populated with the received values instead of initial values.
*1 As an exception, when [Timer Start Event] specifies [Count of operators (Auto Allocate)] under [Count of Cases to Start], as many Cases as there are Operators for the Start Step are started. Although these Cases are started automatically, each Operator becomes the Case Start User, so initial values are set.
*2 Case Start Organization is determined when a Operator selects a role and processes the Start Step. Because initial values are evaluated only at the moment a Case starts, Case Start Organizations determined afterward will not be populated into the Data Item.
In the Expense Reimbursement App, employees start Cases themselves, so the initial value for “Applicant” is populated.
Combining [Required] and Initial Values
Data Items pre-populated with initial values pass [Required] checks without requiring any action from Operators. For “Applicant”, the employee starting the Case applies personally, so completing the Step with the initial value unchanged poses no issue. For “Amount” and “Date of Use”, values change per application, so initial values are not set, and input is prompted via [Required]. “Receipt” also prompts file attachment via [Required].
Validation That Cannot Be Handled by Value Validation
Value Validation evaluates only the value of an individual Data Item on a per-item basis. Conditions that compare values across multiple Data Items (such as checking whether “Transfer Date” is not earlier than “Scheduled Payment Date”) cannot be configured via Value Validation. Such conditions are created using the Questetra Form JavaScript API. For details on how to build them, refer to “Performing Custom Input Validation on Forms“.
Related Documentation
- Chapter 6: Handling Data in Various Formats (First-Time Workflow App Design)
- Designing User-Friendly Forms
- Can Data Items Be Set as Required Only at Specific Steps?
- Performing Custom Input Validation on Forms
- R2051: Data Item Value Validation and System Limits (Subtype List)
- R2052: Format of Initial Value of Data Items
- R2060: Value Validation of String-Type Data Items Using Regular Expressions
