Skip to main content
An inline enum field constrains a column to a fixed list of allowed values, defined directly on the field. It’s the right choice when the list is specific to one column on one table and you don’t need to share it elsewhere. Common examples:
  • A priority field with LOW, MEDIUM, HIGH
  • A visibility field with PUBLIC, PRIVATE
  • A payment_method field with CARD, BANK_TRANSFER, CASH

​
Inline enum vs. user-defined enum

Both options give you the same protection — only listed values are accepted. The difference is reuse: If you find yourself copy-pasting the same enum values onto multiple fields, switch to a Data Type instead.

​
Configuration options

​
How it appears in the API

The field is generated as a typed enum in GraphQL — clients get autocompletion of allowed values and the API rejects any value outside the list. See the GraphQL API Explorer for the generated enum type.

​
Permissions

Inline enum fields are subject to the per-role read and write rules configured in Role-Based Access.

​
FAQ

The moment you want the same list on a second field. Inline enums are independent — editing one doesn’t update any others. A Data Type is shared, so editing it once propagates everywhere.
Records that hold the removed value will fail validation on update until you reassign them. Plan removals carefully — consider migrating affected rows first, then removing the value.
Yes. Adding a value is safe; existing records keep their current values and the new option becomes available going forward.
Renaming changes the enum on the field but does not rewrite existing rows. After renaming, update any rows holding the old value to the new one.