Validation Logic in custom forms

[skyehansen]

I'm opening up a discussion thread for the new functionality described here:

https://experienceleague.adobe.com/en/docs/workfront/using/administration-and-setup/customize/custom...

(validation logic in custom forms)

Please add questions/issues or discovered functionality below. If you're posting something that works please use the format:

*use case

*code

*screenshot of expected result

thanks for your participation!

[DavidCornwellLP]

Amazing work, Bill!

[JohnJOSullivan]

This is AMAZING. Thanks for sharing!

[lmileusnich]

Hello! I'm one of the Workfront technical writers and I've worked with the product manager for custom forms to add more examples of advanced validation logic in the documentation, following your examples. I appreciate your work in putting together these examples that other users can benefit from!

https://experienceleague.adobe.com/en/docs/workfront/using/administration-and-setup/customize/custom...

Cheers,

Lisa Mileusnich

[skyehansen]

thank you Lisa, and I really liked the examples showing use of arraylength! Great addition for us all to look at.

[Rafal_Bainie]

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?

[Kurt_Jones]

I did input a ticket to support to ask about this as I was not seeing it in my preview (along with video and pic), however, after  doing that and having the team review, it does now show in my preview environment which they attributed to a recent maintenance update of the form in prep for the April release.  That said, my comment on needing to be behind the unified shell is no longer valid and the functionality should be showing in a person's preview whether or not they are behind the unified shell.

[skyehansen]

thanks for following up! I appreciate you both. And yes, looking forward to seeing this in production next Thu.

[ChrisStephens]

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.

[KatherineLa]

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

[hnalbandyan]

Hi @KatherineLa. Thanks for sharing your use case. I can suggest the following:
1. You can add a Business Rule to check that all projects created from templates have the company field filled out. The expression might look like this

IF(!ISBLANK({templateID}) && ISBLANK({companyID}), "Please, select a company before creating the project")

Since the company field is not a required field for the project, but you have a logic depending on it, you can try enforcing that field this way.
2. Once a company is selected in the creation dialog, you can slightly modify your original expression and instead of referring to the {companyID} field you can reference the {company}.{ID} field. The logic is that if you are selecting the company object, you can reference its fields as well, the {companyID} field will be populated by the system after the project is created.

IF({company}.{ID} == "Your ID" && {DE:CreativeName} == "", "CreativeName required for This client's Deployments")​

3. Bonus Tip: You can even customize the error message to show the company's name if your use case needs so or it will be more helpful for the end-users. E.g.

IF({company}.{ID} == "Your ID" && {DE:CreativeName} == "", CONCAT("CreativeName required for ", {company}.{name}, "'s Deployments"))

Hope this helps

[CR17506599]

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:

IF(REGEXP({DE:FieldName}, "^[0-9]+$"), "", "Please enter numbers only.");

[Lyndsy-Denk]

@CR17506599 This is an existing setting for fields, so you wouldn't need to set it via validation logic. It exists below the Instructions field. See the screenshot attached.

[CR17506599]

Thank you! I did try that, but unfortunately, it won't let you change the format of the field if you already have custom forms out there that don't match the new format.  In our case we have several hundred forms with fields that contain text that we want to keep for historical purposes. I thought the new validation rules would be a nice middle ground, but can't get them to work for our particular use case.  We could also make a completely new field and hide the old one, not sure if that would hide the field on the forms that already exist though. 

[skyehansen]

I think you just need to keep trying but yes, to your point, regex doesn't work in calculated fields and therefore, validation logic. Yes, you could make a new field, and you would have to hide the old field on every single form, which is not a big deal except that you apparently have hundreds of forms (??).

So an example of what I mean by "trying", which I didn't spend a lot of time on, so I know probably most folks can improve:

IF(ISBLANK(NUMBER({DE:FieldName})),"needs to be a number")

This kind of calculation is an attempt to workaround not having regex, and in your validation logic would work on any case UNLESS your user starts the string off with a number. So if the field you're trying to "fix" doesn't tend to be a combination of numbers and letters, you're probably 98% safe with putting this in place.

But you get my drift --  keep trying, you just need to come up with a bulletproof workaround using the existing expressions on the calculated data expressions reference article. Good luck!

[ChrisStephens]

So you wouldn't be able to use regex, but you can do something like this.

IF(
  NUMBER({DE:Test Field})!={DE:Test Field},
    "Text included!"
)

[skyehansen]

Use case: I wanted to develop a way to enter a time separately from a date. This is for a team who is planning on using workfront objects to store a delivery time (e.g. emails sent at XX time) but often had changes involving time (e.g. for this week, let's send all emails at 2AM instead of midnight).

My first try with the help of copilot, was just to develop a field for HH:MM. I'm still trying to figure out whether I should add AM/PM or make that a separate field.

IF(

  LEN({DE:Time Field})!="5" ||

  LEFT({DE:Time Field},2)<"01" ||

  LEFT({DE:Time Field},2)>"12" ||

  RIGHT({DE:Time Field},2)<"00" ||

  RIGHT({DE:Time Field},2)>"59" ||

  !CONTAINS(":",{DE:Time Field}),

  "Please enter a valid time in HH:MM format (01-12 for hours, 00-59 for minutes)"

)