Validation Logic in custom forms

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.

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:

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.

Hello,

I just found this discussion. Yesterday I opened this thread, as I do not understand how to use the FORMAT() expression on the new Validation logic functionality.

Does anybody see the Formatting Logic option in your instance?

I would love to have the possibility to have different stylings for negative and positive messages within the validation condition.

Regards

Lars

These are all awesome examples.  I have one caveat to add to the conversation that others might come across (such as our instance) is your instance must be within the Adobe unified shell for you to see/use the Validation Logic.  In my case, I do not see a Validation Logic tab to use these features as we're not in the unified shell (you're in the unified shell when your main menu has moved to the left side and is now part of the hamburger menu as opposed to the right side where you see the 9-dot menu).

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:

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 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:

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 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 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:

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

validation expression (pick at least two):

validation expression (pick no more than two):

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.

hi @skyehansen , thanks for starting great discussion!

qq, do you think this will be available in production with 25.4 release. Does this fall under:

or should I confirm this with support?

One problem that I was running into a lot was that you can only have one business rule for an object event type, i.e. you can only have one business rule for project updates, but I needed to be able to apply different rules for different situations.

What I did to handle this was to create a "Business Rule Logic" field, then on the templates this field gets configured to determine which logic should be applied.

I think I almost have my holy-grail of features here. Hoping someone else can close my gap on Scenario Three below to make it perfect.

In my instance, the use-case 'Can we make that field required for only company XYZ?' is incredibly common, and one I've not been able to support without creating extra company-level forms for each client. In this example, I applied field-level logic to a key field that's absolutely required for one specific client but optional for all others, and tested against the companyID of the project.

• Scenario One: The project already existed, coded to that Company. Any attempt to delete the information in that field successfully triggers the expected error.
• Scenario Two: The project is being newly created from a Template that has the Company pre-set to the one that triggers my error. This also successfully triggers the expected error message.
• Scenario Three (Problem-Child): The project is being newly created from a generic Template that does not have a pre-set Company. Here I'm stuck and hoping someone else clever will know the trick. We have access to Business Rules, but I'd rather find a solution available to everyone if one exists.
  • The project's companyID field is not actually populated until the project is saved, so the formula fails to detect the error during creation.
  • I tried using a Native Field reference field as a trigger, without success.
  • I tried using a calculated field that contained the companyID value, also without success

I'm so glad they added this!

Am I going crazy, or does this not seem to support regular expressions?  I was asked to make an already existing text field not allow folks to enter text, only numbers. I thought I could do this using a regular expression, but the validation editor doesn't like the syntax I provide.  Has anyone been able to get something similar to work?

Something like this: