Hello,
If I'm trying to fill out a template field (list field) in Quick Fields using a token, but the value of the token is not in the list, what is expected to happen? I have a Cloud customer telling me that Quick Fields used to leave the field blank if there wasn't an exact match (while they had an on-prem system), but since they switched to Cloud, it'll fill in whatever the token is, even if it doesn't match something in the list.
This is an issue for them because they used to know whether or not they needed to modify this field manually because it would be blank if no match was found. Now, they have to check and make sure the value placed in that field actually is an exact match to what's in the list. I don't honestly know which behavior is expected, or if it changed between versions of Quick Fields, if there's a setting that dictates what happens in this situation, or if they're simply remembering this incorrectly.
Anyone have any insight?
Question
Question
Quick Fields - List field - If token used to fill field value isn't in list, what is expected behavior?
Replies
I'm not sure about Quick Fields, but as long as I can remember Workflow has been able to set values for a List field regardless of whether or not the value was actually in the list.
I've always looked at it more like the "list" is for the User Interfaces to control what they can select, but it's not really a "validation" method like you would see with dynamic fields.
Hi Jason,
I may try making this list dynamic and see if that changes anything. Thanks for the reply!
Both Quick Fields and Workflow are expected to follow the "restrict values" setting on the field. The option can be found in the field properties on the repository administration page.
Hi Miruna,
You're referring to the "restrict values" settings for Dynamic Fields, correct?
The expected behavior is that the field will be marked as invalid with an error indicating the value is not in the field's list of values. This is true in 10.3 and 11 (and probably before that as well). Documents with invalid fields cannot be stored (even if the session is run by Quick Fields Agent), so they will remain in the Quick Fields session until manually fixed and stored.
I am not aware of an option to clear the field if it has an error, nor have we removed any options like that. Depending on the list of values, you may be able to combine a Conditional process and an Assign Token Value process to manually detect if the field value is one of the accepted values and clear it, but this is a fragile workaround (e.g., if the list values changed, you'd need to update the Conditional's condition as well).
Hi Jacob,
In my experience, that is not how list fields actually behave (at least in Workflow) and as far as I recall they have always allowed Workflow to apply any value regardless of whether or not it's in the list.
I would argue that this is actually desirable behavior or at the very least should be "optional" for a few key reasons.
- Sometimes we want to remove list items so users can no longer select them, but we would not want to remove/change those values if they are set on "legacy" documents.
- When we replicate documents between repositories, we don't want to cause errors or have a new field get added if the lists configured in each repository are not identical.
- We get a lot of documents from third-parties via Import Agent and it is much more convenient for us to just have the repository accept any value we set for a List field. I also I recall an issue way back where we had to use a "placeholder" text field and transfer the value via Workflow after import because the Lists fields were not working the way we wanted/expected in IA.
The following is from an environment running the latest version 11, but I've done similar things for about as long as I have been working with Laserfiche.
Yep, that all makes sense. The list field in question here is a list of vendors, and my fear here is that users will run a search based on an option in the list and miss results because some of these weird ones won't be an exact match. Could always use a wildcard, but we also don't know where exactly in the field value the inconsistency might be, and it feels like we shouldn't have to account for that to run a search for all checks written to a certain vendor, for example.
Wonder if setting this up as dynamic fields instead, and restricting the values is what we should do here.
To be clear, I was only talking about Quick Fields' handling of list fields. The repository, Import Agent, and Workflow all have their own handling of list fields, but since Quick Fields has a review process (document revision), with field validation, it uses that system.
That said, I understand your points and recognize that list fields are used for different purposes (e.g. restricting values vs. suggesting values) and that an option for disabling the list field validation (or clearing the value if it doesn't match) would be useful. I'll pass the idea along to our team supporting the product.