Validation Logic in custom forms
Use case -- "we want our users to provide an answer to a question, that is less than X number of characters"
Sample code:
IF(LEN({DE:Single Line Text Field})>50,"Please choose a name that is less than 50 characters")
Expected result: attached file
Use case -- "we have a 2 week SLA, but our requesters always seem to randomly pick tomorrow as a due date"
Sample code (this is specifically addressing a request queue, so works because the request hasn't yet been submitted (entry date is blank). Requesters could get around it by submitting and then changing the due date -- so admins should consider setting up additional code to guard against this.
IF(ISBLANK({entryDate}),IF({DE:Date Field}<ADDWEEKDAYS($$TODAY,10),"Please allow us at least 2 weeks to complete your request"))
Expected result:
Really excited about this functionality, sooo many times I've been asked if we can put validation on custom fields.
Here's a use case i think would be good
Use Case: We need to prevent people entering special characters into a text field as the field is integrated with a system (AEM Assets) that doesn't support special characters
Sample code:
IF(CONTAINS("*",{DE:DAM_Asset name})||CONTAINS("/",{DE:DAM_Asset name})||CONTAINS(":",{DE:DAM_Asset name})||CONTAINS("[",{DE:DAM_Asset name})||CONTAINS("]",{DE:DAM_Asset name})||CONTAINS("|",{DE:DAM_Asset name})||CONTAINS("#",{DE:DAM_Asset name})||CONTAINS("%",{DE:DAM_Asset name})||CONTAINS("?",{DE:DAM_Asset name})||CONTAINS("&",{DE:DAM_Asset name})||CONTAINS("\\",{DE:DAM_Asset name})||CONTAINS("{",{DE:DAM_Asset name})||CONTAINS("}",{DE:DAM_Asset name}),"Special characters are not supported. Please only include alphanumeric characters.")
Expected result:
NOTE: getting this text mode to work was a bit "finicky" as certain special characters represent different things in text mode. i.e., curly brackets don't like to be read as a string since they are used to represent data attributes. Backslash was a pain as it's used to escape a character so I had to "escape the backslash" and add "\\" instead of "\". Might need more thorough testing to make sure all special characters are recognised appropriately, but in my quick testing I managed to get {}\/ to get recognised.
Hands down the most exciting enhancement to Workfront since I began supporting it back around 2018. I never thought it would actually happen even in my most vivid fantasies. Been experimenting with it for a few days now, here's some examples and takeaways:
1. Exceptions handling: Keep in mind that applying any validation logic results in a required value for the field, even if the field is not set to "Required" in the form builder. Therefore if you want to enable validation for fields that are optional (maybe a value isn't provided until later in the project lifecycle), then you have to build logic into your statement that allows blank values.
Second, ask yourself under which circumstances might you need to override the data validation and then build logic to support that. E.g. if you create a validated Date field that only allows date selections that are beyond $$TODAY + 7d, keep in mind that if that date ever needs to be updated, the same rule will apply at the time of edit. So, if I initially choose "March 10" on a field on March 1, then on March 15 I need to correct the data to "March 17" I won't be able to do so. Takeaway: build in override logic to allow you to edit the values under certain conditions. This might be a "Data Override" checkbox that exists in a form section that is only visible/editable by admins or users with Manage access to the record. Or, the logic may not be enforced if the user is the project owner so owners can input any value on their project forms, but all other users are held to the validation rules. These support multiple conditions using && and || operators, so use those to create multiple conditions under which a value may be considered valid.
2. Error handling: the logic by which a value is not valid, followed by the logic to inform user that a value is not valid. You do not have to limit yourself to static invalid value statements. You can create advanced expressions to display dynamic invalid expressions. E.g. instead of something like "Minimum 100 characters required" you can create text mode to display "45 characters / 55 min. remaining" that acts as a live counter while the user inputs data.
3. Leveraging relationships: You can create logic that references other fields in the form, or logic that references the record's relationships. E.g. you can use logic like {ownerID} to reference the record's owner, so logic isn't enforced for them, or only the record owner is allowed to edit a field, etc. One example I will share below is "only project owner can select 'Rush' value in a dropdown. The 'Date Requested' field then allows for a date selection that would not otherwise fall within the SLA.
4. Inline editing: amazingly, validation is enforced in inline editing of values from list view. There are caveats to this, especially if you use the same field on multiple forms and this is compounded if that same field has different validation logic on the forms in which it appears.
Examples:
___________________________________________________________________
A. Only allow Project Owner to select "Rush" SLA
validation expression:
IF({ownerID}!=$$USER&&{DE:DV - Dropdown - Control Dates}="2",CONCAT("Only ",{owner}.{name}," may select X Rush"))
When anyone who is not the project owner (including admins) attempts to select "X Rush" an error is displayed:
B. This can also feed into downstream validated fields:
validation expression:
IF({DE:DV - Date - Dropdown SLA}<ADDDAYS($$TODAY,{DE:DV - Dropdown - Control Dates}),CONCAT("Earliest: ",ADDDAYS($$TODAY,{DE:DV - Dropdown - Control Dates})))
If the user selects a date prior to that which is allowed, they're informed of the earliest date that can be selected:
___________________________________________________________________
C. Error handling with character count, option to override based on "Override checkbox"
validation expression:
IF({DE:DV - Override}!="Disable Validation"&&LEN({DE:DV - Text - Min Length})<"7",CONCAT(LEN({DE:DV - Text - Min Length})," characters / ",("7"-LEN({DE:DV - Text - Min Length}))," remaining"))
enforcement can be overrided by checking this box:
and includes a running character count:
___________________________________________________________________
D. Lock specific fields to only allow record owner to input/edit:
validation expression:
IF({ownerID}!=$$USER,IF(ISBLANK({ownerID}),"Project Owner will provide this.",CONCAT("Only ",{owner}.{name}," can edit this.")))
If the user is not the owner, they are shown a character counter displaying how many characters entered/remaining:
___________________________________________________________________
E. Create a Typeahead that dynamically allows/rejects values based on other form inputs. In this example, if the user has input more than $10,000 in a budget field, they can only select a user in a subsequent User Typeahead field who is assigned a role of "Director"
validation expression:
IF({DE:DV - Override}!="Disable Validation"&&{DE:DV - Text - Budget}>"10000"&&{DE:DV - TA User - by Budget}.{role}!="Director","Requires Director Approver")
If the value in upstream field "DV - Text - Budget" is more than $10,000 only users with a Director role can be selected from the typeahead, even if there is no role filter enabled on the typeahead configuration.
___________________________________________________________________
F. Disallow values that are less than 10 days from the entry date; allow override; and allow blank values to keep the field optional:
validation expression:
IF({DE:DV - Override}!="Disable Validation"&&ISBLANK({DE:DV - Date - Deadline})!="true"&&{DE:DV - Date - Deadline}<ADDDAYS({entryDate},"10"),CONCAT("Earliest: ",ADDDAYS({entryDate},"10")))
Any value will trigger validation:
Blank value still allowed:
___________________________________________________________________
G. Enforce exact/minimum/maximum selections in a multi-select field. (Uses the new ARRAY functions):
validation expression (pick exactly two):
IF({DE:DV - Override}!="Disable Validation"&&ARRAYLENGTH(ARRAY({DE:DV - Checkbox - Pick exactly 2},","))!="2","Pick Exactly 2 Options")
validation expression (pick at least two):
IF({DE:DV - Override}!="Disable Validation"&&ARRAYLENGTH(ARRAY({DE:DV - Checkbox - Pick at least 2},","))<"2","Pick at least 2 choices")
validation expression (pick no more than two):
IF({DE:DV - Override}!="Disable Validation"&&ARRAYLENGTH(ARRAY({DE:DV - Checkbox - Pick no more than 2},","))>"2","Pick no more than 2 choices")
User then sees validation errors:
___________________________________________________________________
Lots more possibilities in both the validation rules and the messages displayed to user during input. I look forward to seeing other examples and sharing more of my own as we uncover interesting use cases.
Will, this is awesome. Thanks for sharing, I didn't fully appreciate the extent that these validation rules could go to until your post!
Related Conversations
