Auto-clear hidden dependent field values on visibility change

════════════════════════════════════════════════════════════════════

WHAT IS YOUR IDEA? (Description)

════════════════════════════════════════════════════════════════════

Provide a configurable, out-of-the-box option so that when a dependent

(conditionally-displayed) field is HIDDEN because its driving field value no

longer meets the show condition, the dependent field's stored value is CLEARED

rather than silently retained.



Today, dependent-field visibility is purely presentational: hiding a field only

changes whether the user can see it — the value stays on the record. When the

driving field is later changed back so the dependent field re-appears, it shows

the OLD value the user entered earlier, even though the condition that justified

that value was, in between, no longer true.



The requested option would ideally be:

  • Configurable per dependent-field dependency (opt-in), so existing behaviour

    is unchanged by default and admins choose where clearing applies.

  • Applied consistently in Create View and Task View, and reflected in exports

    (FastMap) and reporting so downstream data is not carrying stale values.

  • Independent of field calculations (a calculation makes the field read-only,

    which prevents normal data entry, so calculations are NOT a viable

    workaround — confirmed by IBM Support).





════════════════════════════════════════════════════════════════════

BUSINESS NEED / USE CASE (Why is it needed?)

════════════════════════════════════════════════════════════════════

Conditional fields are commonly used to capture data that is only relevant for a

specific driving-field value. Example on the Risk object:

  • "Risk Acceptance Date" and "Risk Acceptance Review Date" appear only when

    "Risk Treatment" = Accept.

  • A user sets Risk Treatment = Accept, enters the acceptance dates, and saves.

  • The user later changes Risk Treatment to Avoid — the acceptance-date fields

    are correctly hidden.

  • If Risk Treatment is set back to Accept, the acceptance-date fields re-appear

    still holding the OLD dates — no prompt, no clear, no error.



Business impact:

  • DATA INTEGRITY: stale values persist on records whose driving value has

    changed. The retained value may no longer be valid for the current state of

    the record.

  • AUDIT / COMPLIANCE: in a GRC platform, inaccurate risk-acceptance dates

    (and similar conditional data) can misrepresent the control/risk posture and

    surface in exports and reports.

  • USER TRUST / EFFORT: reviewers and approvers cannot tell that a re-shown

    value is stale; teams must manually detect and clear such fields, which does

    not scale across many records and many conditional fields.



This is not specific to one field or object — it affects ALL conditionally-

displayed dependent fields across objects. A supported, configurable "clear on

hide" option would let organisations keep conditional data accurate without

custom workarounds.





════════════════════════════════════════════════════════════════════

CURRENT BEHAVIOUR (as confirmed by IBM Support)

════════════════════════════════════════════════════════════════════

"Having a field be hidden/visible does not change the value in the field. It

simply makes it visible to the end user or not. The field value is retained...

There is no OOB functionality that would remove the field's value when the field

is hidden." — IBM OP Technical Support.



Documentation reference:

https://www.ibm.com/docs/en/openpages/9.2.x?topic=types-configuring-dependent-fields





════════════════════════════════════════════════════════════════════

PROPOSED / EXPECTED BEHAVIOUR

════════════════════════════════════════════════════════════════════

Add an admin-configurable setting on a dependent-field dependency, e.g.

"Clear field value when hidden = Yes/No" (default No, preserving today's

behaviour). When enabled:

  • On a driving-field change that hides the dependent field, the dependent

    field's value is cleared as part of that change.

  • On save, the cleared value is persisted (the field returns empty when it is

    next shown, ready for fresh input).

  • Behaviour is consistent across Create/Task views, workflow transitions,

    FastMap import/export, and reporting.





════════════════════════════════════════════════════════════════════

WORKAROUNDS CONSIDERED (and why they don't work)

════════════════════════════════════════════════════════════════════

  • Field calculation to blank the value: rejected — a calculated field becomes

    read-only, so users could never enter a value in the first place

    (confirmed by IBM Support).

  • Manual clearing by users: not scalable and error-prone across many records

    and many conditional fields; no signal tells the user the value is stale.

  • Custom triggers/helper code: not out-of-the-box, adds maintenance burden and

    upgrade risk.





════════════════════════════════════════════════════════════════════

PRIORITY / IMPACT (for the portal fields)

════════════════════════════════════════════════════════════════════

  • Product: OpenPages with Watson (OPP)

  • Component/Area: Dependent (conditional) fields / Object field configuration

  • Affects: all objects using dependent fields (example: Risk object,

    Risk Treatment -> Risk Acceptance Date / Risk Acceptance Review Date)

  • Priority (suggested): Medium/High — data-integrity & audit relevance in a

    GRC context

  • Versions observed: OpenPages 9.x (DEV)