Plan requirement
| Subscription | Any plan |
| Access | Admin |
Business rules can read a field the form does not show, but nobody can fill it in. That distinction matters.
Can a field work if it is not on the form?
A trigger can set a field that is not on the form, and a view can filter on it. The field exists on every ticket whichever form is in use; the form only decides what is displayed.
That holds even when a ticket is switched to a form without the field: triggers and automations can still read and act on its value. Useful for fields nobody should touch, set by a rule and used for routing or reporting.
Related: a field marked required for solving a ticket can be bypassed by triggers and automations. Required stops an agent, not a rule.
What does not work
Nobody can fill in a field they cannot see, agent or customer, and a macro that sets it silently does nothing. That is the usual cause of a field that is always empty.
So when is that the right design?
When it is deliberate: rule-set fields off the forms, and every field a human must fill in on the form they use. Trouble comes from doing it by accident, with a field added and never placed anywhere.
How to tell which you have
Look at whether anything sets the field. If a trigger does, it is working as intended. If nothing does and it is on no form, the field is doing nothing at all.
Deactivate rather than delete: deactivating is reversible and deleting is not. What each does to your tickets and rules is set out separately.
A new field also appears on existing tickets straight away with an empty value, which is not bad data.
Comments
0 comments
Article is closed for comments.