AddThisFeature

Custom Fields

Let each workspace add the extra fields their process needs.

involved Data & Content

What it adds

User-defined fields with stable IDs, typed validation, server-enforced visibility, and defined behaviour on type change and deletion.

What your agent is told to do

5
  1. 1

    Give every field a stable internal ID that never changes, and treat the label as display-only. Renaming a field must not touch a single stored value — key data by ID, never by label.

  2. 2

    Support a small, deliberate set of types: text, number, date, single-select, multi-select, checkbox, and user reference. Each type validates on the server; a client-side date picker is not validation.

  3. 3

    Enforce per-field visibility and editability by role on the server, and apply the same rules to list views, exports, filters, and API responses — not just the record form.

  4. 4

    Handle type changes explicitly: check every existing value against the new type first, show the user how many would fail, and refuse or quarantine rather than silently blanking them.

  5. 5

    Do not let custom fields become an unbounded schema. Cap the field count per record type and reject deeply nested or free-form JSON values — an untyped bag of data cannot be validated, filtered, or exported reliably.

Edge cases it handles

6
  • Making a field required after records exist must not block editing every old record. Enforce it on new saves and report the backlog.
  • Deleting a field needs a defined fate for its data: soft-delete and retain, or purge with an explicit warning and count.
  • Removing an option from a select while records still use it must either keep it as a read-only legacy value or force reassignment.
  • Exports and imports must round-trip custom fields by ID, so a re-import does not create duplicate fields with the same label.
  • Filtering and sorting on custom fields needs indexing thought through; an unindexed value column turns every list query slow as the workspace grows.
  • A user-reference field must handle the referenced user being deactivated or removed from the workspace.

Definition of done

8
  • Values are stored against stable field IDs, and renaming a field loses no data.
  • Every field type is validated on the server, not only in the form.
  • Field-level visibility and edit permissions apply to forms, lists, filters, exports, and API responses.
  • A type change reports how many existing values would fail before anything is written.
  • Field deletion and select-option removal have documented, non-destructive-by-default behaviour.
  • There is a cap on fields per record type and free-form nested values are rejected.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.