Now with AI-powered page building via MCP Server

User properties

Custom fields stored on your users, grouped into named properties, with an optional schema.org mapping for structured data.

Models describe your content. Properties describe your people - the custom fields stored on users beyond name and email.

You will find them in the workspace under Settings → User Properties. The screen itself is titled Custom Properties; same feature, two names.

A property is a group of fields

A property is not a single field. It is a named group, which is what lets one concept - Employment, Speaker profile, Shipping address - hold several related values without scattering them.

Each property has:

  • Name - what editors see, e.g. Role or Department.
  • Slug - the unique identifier you reference in code.
  • Description - what it is for.
  • Allow multiple values - whether a user can hold more than one instance. A person has one date of birth but can have several certifications.

Inside it, one or more fields, each with a label, a key, a type, an optional description and a required flag.

Field types

The same palette you know from block schemas:

  • Text - text, rich text, markdown, password.
  • Numeric and boolean - number, yes/no.
  • Contact - email, URL.
  • Choice - select (one), multi-select (many).
  • Time - date, date and time.
  • References - media, relation.
  • Structured - object (a group), list (a repeater), table, JSON.

Because relation is available, a user property can point at your model records. A Speaker property can reference the sessions someone is presenting, and those sessions stay in one place rather than being retyped per user.

Schema.org mapping

This is the part worth reaching for deliberately. Each field can name a schema.org property - author, image, description - and cmssy uses it to place the value in your structured data as JSON-LD.

The value of that is concrete: an author bio that is merely rendered is text on a page; the same bio mapped to author is a machine-readable claim about who wrote the article. Search engines and AI crawlers read the second one.

Leave it as None when a field has no meaningful public equivalent. A wrong mapping is worse than an absent one - it asserts something untrue about your content in a format built to be trusted.

Permissions

Two permissions govern the feature, and the split is deliberate:

  • properties:view - see the property definitions.
  • properties:manage - define custom user and content properties.

Defining a property is a schema change, not data entry. It belongs with the people who own the shape of your data, which is why it is not bundled into ordinary editing rights.

Deleting removes the data

Deleting a property definition removes that field from every user, and it cannot be undone.

This is not a soft delete or a hidden column. If a property has been filled in across hundreds of users, export what you need before removing it - the confirmation dialog is the last point at which that data exists.

Next steps