> For the complete documentation index, see [llms.txt](https://docs.agilecase.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.agilecase.com/developer-documentation/custom-form-scripting/examples/showing-and-hiding-dependent-fields.md).

# Showing and Hiding Dependent Fields (Using Rulesets)

The standard config label — hide its own row, then run one rule.

This is the most common JavaScript label in AgileCase, and the shape to learn first. The label displays nothing. It hides itself, and its whole job is to run a [ruleset](/developer-documentation/custom-form-scripting/rule-reference.md) that decides which of the other fields on the tab are visible.

## The scenario

A charity records the outcome of the first call to a new volunteer. Call notes are only worth asking for when somebody actually answered, so the notes box should appear only when the outcome is "Contact Made".

| Setting      | Value                                  |
| ------------ | -------------------------------------- |
| Config label | `6107` Volunteer call config, hidden   |
| Trigger      | `6108` Initial call outcome (dropdown) |
| Target       | `6109` Call notes (text area)          |

## The script

```javascript
ThisJSLabel().HideRow();

var showNotesWhenContactMade = [{
    "action": "hide",
    "trigger_id": 6108,
    "target_ids": [6109],
    "test_type": "NOT_EQUALS",
    "test_values": ["Contact Made"],
    "description": "Show call notes only when the outcome is Contact Made"
}];

ExecuteAllRules(showNotesWhenContactMade);
```

## Hiding the label itself

`ThisJSLabel()` is the label running the script, and `HideRow()` hides its whole row, caption included. Without that first line, users see an empty field with a label on it and no idea what it is for.

This is why config labels are usually named for what they do — "Volunteer call config" — rather than for what they show. Nobody but the next person to edit the script will ever see the name.

## Reading the rule backwards

The action is `hide`, so the rule hides its targets when the test **passes**. To show a field when the outcome is "Contact Made", the test has to be "the outcome is not Contact Made".

The rule reads the opposite way round from how you would say it out loud, so it helps to read it in the order it is written: *hide 6109 when 6108 is not "Contact Made"*. The `description` is there to carry the other version, and stating the intention rather than the mechanism — "show call notes only when..." — is the more useful thing to put in it.

## Why there is nothing to bind

There is no change handler here, and none is needed. The label re-runs on every change to any field on the form, so the ruleset is re-applied after every edit and the layout always reflects the current values.

That is also why the rule needs no opposite. `hide` shows its targets when the test fails, so a user who picks "Contact Made" and then changes their mind sees the notes box disappear again.

## Growing it

The array holds as many rules as the tab needs, and they are all applied in one pass. Adding a second dependency means adding a second object, not a second label — see [Driving a Layout From Several Rules](/developer-documentation/custom-form-scripting/examples/driving-a-layout-from-several-rules.md).

{% hint style="info" %}
`hide` leaves the target's value alone, so a field that is filled in and then hidden still submits what it holds. Where that would be wrong — an answer that no longer applies — use [`hide_and_blank`](/developer-documentation/custom-form-scripting/examples/hiding-and-blanking-dependent-fields.md) instead.
{% endhint %}