> For the complete documentation index, see [llms.txt](https://docs.codemash.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.codemash.io/cloud/database/collections/create-schema.md). # Create a Schema {% hint style="info" %} Creating a collection **is** creating its schema: start from a ready-made template you adjust, or from a blank schema (`/projects//db/collections/new` → builder at `…/db/schemas/new`). {% endhint %} Every collection is defined by **two schemas** that you edit together: * the **Data schema** — what is stored and validated: fields, types, and rules. It is standard JSON Schema — strings (with formats like `email`, `uri`, `uuid`), integers, numbers, booleans, dates, arrays, objects, plus Norbix widgets such as **geolocation**, file references, taxonomy terms, and record references. * the **UI schema** — how the record form looks: **tabs** → **containers** (with headers) → **cells** on a 12-column grid, each cell pointing at a field with its widget, label, and required flag. From these two documents Norbix generates everything: the validation, the record form in the dashboard, and the CRUD + query API. ## Step by step **1. Start a new schema.** Open **Database → Collections**, create a collection (or open one and go to its **Schema** tab). A new schema starts empty in the **Visual Builder**:

A new, empty schema in the Visual Builder.

**2. Open the JSON editor.** Press **JSON**, then **Edit JSON**. Two editors appear — the **Data schema** on top, the **UI schema** below. This view is ideal for pasting a schema from another project or a template:

The JSON view: Data schema (top) and UI schema (bottom).

**3. Define both schemas.** Fill the Data schema first (fields, types, validation), then the UI schema (tabs, containers, grid cells). Here both are filled with the kitchen-sink example that uses every field type:

Both schemas filled. The save button enables only when both documents are valid JSON.

**4. Save and switch to the Visual Builder.** Press **Save schemas' changes**, then **Visual Builder**. The builder hydrates from your JSON — tabs across the top, every field in its container and grid cell:

**5. Check every tab.** Each UI-schema tab becomes a builder tab — switch through them to verify the layout:

The Numbers & Dates tab — numeric and date fields with their widgets.

The Contact & Refs tab — email/URL formats, references, and the geolocation widget.

**6. Publish.** Schemas are **drafts** until you publish. Publishing creates a new schema **version**; records keep working during edits, you can diff versions, and you can discard a draft to return to the published version. Below — the builder after loading a "kitchen sink" schema that uses every field type, laid out in three tabs (Basics, Numbers & Dates, Contact & Refs):

Schema builder with every field type — The Visual Builder hydrated with all field types — tabs on top, containers and grid cells inside.

{% hint style="info" %} The same schema drives the record form your team uses in the dashboard and the validation applied to every API write — change it once, both follow. {% endhint %} ## Editing an existing schema Open a collection's **Schema** tab (`/projects//db/schemas//edit`) to reopen the same builder on a live schema. Changes are saved to a **draft** first — existing records are untouched until you **publish**. The version history lets you diff what changed between publishes. ## Use it from code Schemas are fully manageable from the SDKs — drafts, publishing, versions, diffs: [Database → Schemas](/sdks-and-cli/database/schemas.md). ## API reference Endpoints: [Database → Schemas](/api-reference/database/schemas.md).