Capture form visibility/display with fusion?

Rich is correct in that is only visible in the UI Fusion does not have a supported runtime field such as isVisible that tells it whether a Workfront custom-form field is currently displayed to a user. Workfront display logic controls the form UI; it does not remove the value stored on the request.

Therefore, when Field 1 = No hides Field 2, the existing value in Field 2 can still be returned to Fusion and used by an automation. This is expected behavior. Workfront display logic does not clear hidden field values

Workfront documents display logic as a rule that determines which custom fields appear on the form; it should not be treated as a data-clearing or data-filtering rule. Add Logic Rules to Custom Forms and Fields

Recommended Fusion design

Reproduce the same business condition in Fusion instead of checking visibility:

1. Watch for a new or updated request.
2. Read Field 1 and the dependent fields.
3. Add a router or filter:
   • If Field 1 = Yes, process Field 2.
   • If Field 1 != Yes, ignore Field 2 for business processing.
4. Place this filter before the modules that use Field 2.

For example:

Process Field 2 only when:

Field 1 equals Yes
AND
Field 2 is not empty

If the display rule has multiple conditions, reproduce the complete rule in the Fusion filter. Do not use the presence of a value in Field 2 as proof that the field is currently visible.

you may need to consider a clean up approach as well.

If hidden values should never remain on a request, add a cleanup route:

Request created or updated
        |
        v
Read Field 1
        |
        +-- Field 1 = Yes --> Continue normal processing
        |
        +-- Field 1 != Yes --> Clear Field 2 --> Stop

The cleanup route can use the Workfront Update Record module to set the dependent custom field to an empty value. Test the clearing behavior for each field type—text, date, single-select, checkbox, and multi-select—because the empty representation can differ. Leaving a field unmapped usually means “do not change it,” not “clear it.”

Adobe documents that Fusion’s Workfront modules can update custom-form fields and that the Workfront copy action has a clearCustomData option. Adobe Workfront modules

Important consideration for copied requests

If the request is copied through Fusion and all custom data should be removed, the Workfront Misc Action → Copy → clearCustomData option may be appropriate.

However, that option clears all custom data. If some visible field values must be retained, do not use it. Instead:

• Allow the request to be copied.
• Trigger Fusion when the new request is created.
• Evaluate Field 1.
• Clear only the dependent fields that are not applicable.
• Run the business automation only after that cleanup step.

If the request is copied manually in the Workfront UI, use a request-created trigger or a scheduled search to perform the same selective cleanup.

Best practice

For automations, treat display logic as a user-experience feature rather than as the source of truth. Use an explicit field such as:

Field 2 Applicable = Yes/No

or make the controlling field itself the source of truth in every Fusion filter. This prevents stale hidden values from driving downstream actions.

Also note that display logic should not be relied on as a security mechanism: hiding a field does not prevent its stored value from being read by an authorized API or Fusion connection.

This may or may not be suitable for your use case, as you would be rebuilding the logic in fusion but it may help.