Create a Schema

Build a collection schema — data structure, UI layout, and publishing.

Creating a collection is creating its schema: start from a ready-made template you adjust, or from a blank schema (/projects/<project>/db/collections/new → builder at …/db/schemas/new).

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:

The Basics tab after hydration.

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):

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

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.

Editing an existing schema

Open a collection's Schema tab (/projects/<project>/db/schemas/<schemaName>/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.

API reference

Endpoints: Database → Schemas.