Visibility Rules

A visibility rule decides whether a field shows up at all, based on the values of other fields. They make forms feel responsive: the user enters a fact, and only the questions that follow from it appear.

A few quick examples:

Field	When to show it
Cause of death	When “Is alive” is unchecked.
Spell components — material	When “Components” includes “Material”.
Player name	When the character’s subtype is “Player Character”.
Capital city	When “Is capital” is checked.

Without rules, every character would have a “Cause of death” field on their form. Rules turn that into “you only see it if it’s actually relevant”. The form feels like it knows what you’re doing.

Three actions

A visibility rule chooses one of three things to do when its condition is met:

Action	Effect
Show	The field appears only when the condition is true (otherwise hidden).
Hide	The field hides when the condition is true (otherwise visible).
Disable	The field is visible but greyed out and not editable when the condition is true.

Most of the time you’ll want Show. Use Hide when the field is normally there and you only need to remove it in unusual cases. Use Disable when you want users to see the field but not change it (e.g. a status field that’s locked once an entity is archived).

Adding a visibility rule

1. Open the type’s Behaviours tab and click Add Behaviour.
2. Choose Visibility.
3. Pick the target field — the one that will be shown, hidden, or disabled.
4. Pick the action — show, hide, or disable.
5. Add one or more conditions. Each condition compares another field’s value against something.
6. (Optional) combine conditions with AND or OR if you have more than one.
7. Save.

Conditions in detail

A condition is a small statement like Subtype equals “Protagonist” or Level is greater than 5. Each condition has three parts:

1. Field — which other field to look at.
2. Comparison — how to compare it.
3. Value — what to compare it to (when needed).

The comparisons available depend on the field type. Common ones:

Comparison	Works with	Reads as
equals	most fields	”Is this exact value”
does not equal	most fields	”Is anything but this value”
contains	text and lists	”Has this somewhere inside”
does not contain	text and lists	”Doesn’t have this anywhere”
is empty	most fields	”Hasn’t been filled in”
is not empty	most fields	”Has been filled in (anything)“
greater than	numbers and dates	”Bigger than this number”
less than	numbers and dates	”Smaller than this number”

Combining with AND / OR

You can stack several conditions on one rule:

• AND — every condition must be true.
• OR — any one condition being true is enough.

When you add a second condition, you’ll see a small AND/OR toggle between them. Set it once for the whole group; you can’t mix AND and OR in the same group.

If you need more complex logic — (A or B) and C — group your conditions:

• Add a top-level group with the AND combiner.
• Inside that, nest a sub-group of OR conditions.

The editor supports two levels of nesting, which is enough for almost any rule. If you find yourself wanting more, that’s usually a sign the form would be clearer split into different subtypes.

A worked example: hiding fields by subtype

Say your Character type has subtypes Protagonist, NPC, and Historical Figure, and you want each to show different fields.

For each “Protagonist-only” field (Goal, Internal Conflict, Character Arc):

1. Add a visibility rule with action Show.
2. One condition: Subtype equals Protagonist.
3. Save.

For each “NPC-only” field (Role, Default Attitude):

1. Visibility rule, action Show.
2. Condition: Subtype equals NPC.
3. Save.

Now the form auto-adapts:

• A protagonist character shows the universal fields plus Goal, Internal Conflict, and Character Arc.
• An NPC shows the universal fields plus Role and Default Attitude.
• A historical figure just sees the universal fields (plus any Historical-Figure rules you’ve added).

This pattern is by far the most common reason to add visibility rules. It scales well — start with all fields visible, then mark the niche ones with a rule when you realise they’re only used in some cases.

Another example: optional follow-ups

Say your Character form has a checkbox Is deceased. When checked, you want users to fill in Cause of death and Date of death.

Both follow-up fields get a visibility rule:

• Action: Show
• Condition: Is deceased equals true

The fields disappear for living characters and appear immediately when the checkbox is ticked.

Tips

Default to “Show”, with one condition. Most useful rules read as “show this field when X is the case”. Resist the urge to combine many conditions; the resulting form behaviour gets confusing.

Avoid hiding required fields. A field that’s required and hidden by a rule means the user can be blocked from saving without knowing why. If you need this, mark the field optional and validate elsewhere.

Test by switching between subtypes. When you set up a subtype-based rule, create a test entity and switch its subtype while editing. Fields should appear and disappear smoothly.

Visibility doesn’t delete data. A field hidden by a rule still keeps any value previously entered. Re-show the field and the old value is still there.

Where to go next

Auto-calculated fields Combine visibility rules with auto-calculation for forms that update themselves.

Subtypes The classic partner for visibility rules — different fields per subtype.