Behaviour Rules

Once you’ve defined fields and arranged them on a form, you can teach the form to react. Behaviour rules make a field appear only when relevant, fill itself in based on other answers, or only show when a feature is enabled in your world.

A few examples to ground what behaviours can do:

“Cause of death” only appears when “Is alive” is unchecked.
“Age” calculates itself from “Birth date” and the current world date.
“Map coordinates” only shows when the Maps feature is on.
“Total wealth” sums the value of every Item the character owns.

You don’t need behaviours to ship a working entity type. They turn a good form into a great one — fewer irrelevant questions, fewer manual sums, less chance of inconsistency.

The three kinds of behaviour

Visibility rules Show, hide, or disable a field based on conditions. The most useful behaviour and where most people start.

Auto-calculated fields Fields whose value is computed by the system instead of typed in. Age from birth date, totals from owned items, full names from first + last.

Feature requirements Hide a field unless a specific world feature is enabled. Useful for fields that only make sense once you've turned on Maps, Timelines, or Calendars.

Adding a behaviour

Open Management → Entity Types, pick the type, and switch to the Behaviours tab. You’ll see three category cards at the top showing how many of each kind you have, and a list of the rules below.

Click Add Behaviour to open the editor. The editor walks you through:

What kind of behaviour (visibility, auto-calculate, feature).
Which field the rule applies to.
The rule itself — the condition or formula or feature ID.
(Optional) a priority if you have several rules on the same field. Higher priority wins.

Save, and the rule takes effect on the next form load.

Feature requirements

Feature requirements are simple: pick a field, pick a feature ID, and the field is shown only when that feature is enabled in the world’s settings.

This is mostly used for fields that don’t make sense without an opt-in feature being on. A few examples:

Field	Required feature	What happens
Map coordinates	Maps	The field disappears in worlds where Maps is off.
Birth date in calendar	Calendars	Hidden until the user has set up a calendar.
Power level	Magic	Only relevant for worlds with the Magic domain enabled.

You set the feature ID in the rule editor — it’s a short identifier like maps, timelines, or magic. Feature IDs come from the World Settings page, where you can see what your world has enabled.

Behaviour priority

If two rules touch the same field, priority decides which wins. Rules with higher priority numbers run first. You’ll rarely need this — most fields end up with at most one rule of each kind.

When it does matter:

A visibility rule and a feature requirement on the same field — feature requirements always win when their feature is off.
Two visibility rules with conflicting conditions — the one with higher priority decides.

What you can’t do (yet)

A few things behaviour rules don’t currently cover:

Custom validation — you can’t write a rule like “death date must be after birth date” yet. The basic constraints (required, min/max, length) on each field cover most cases.
Per-user permissions — you can’t hide fields based on who’s viewing. The same form is shown to everyone with access to the world.
Side effects — behaviours don’t trigger emails, webhooks, or workflows. They only affect what shows on the form and what auto-calculated fields display.

If you’ve got a use case that doesn’t fit, the best move is a visibility rule plus a clear field description telling users what to do.

Where to go next

Visibility rules Show or hide fields based on what's been entered elsewhere.

Auto-calculated fields The four ways the system can fill in a field for the user.

Common pitfalls Gotchas with behaviours, including circular references.