Inline Schemas

Inline schemas let you create reusable content components that can be embedded inside other models. Think of them as custom building blocks — once you create one, it appears as a field type you can add to any model.

Overview

An inline schema is a model whose fields can be embedded directly within another record’s data, rather than existing as a separate record with its own ID. For example:

• A Hero Banner with heading, image, and call-to-action button
• A Testimonial Card with quote, author name, and photo
• A Feature Block with icon, title, and description

Once created, these appear alongside the built-in field types (text, number, image, etc.) when adding fields to any model.

How It Works

1. Create a model with the Inline (Block) kind and the fields your component needs
2. The model’s key now appears as a field type in other models
3. When editors fill in that field, they see a structured form matching the inline schema

Model Kind

Every model is one of two kinds, chosen when you create it and locked thereafter:

Inline (Block) — Can be embedded in other content, but has no records of its own. Best for components like buttons, cards, and hero banners.

Record-bearing (Standalone) — Creates individual records managed separately. This is the default for all models. Best for pages, blog posts, and products.

A model is one kind or the other — it cannot be both, and the choice cannot be changed after creation.

In the Admin

Creating an inline schema

1. Go to Settings > Models
2. Click Create Model
3. Fill in the details:
   • Name: “Hero Banner”
   • Key: hero-banner (auto-generated from name)
4. Add fields:
   • Heading (text, required)
   • Subheading (text)
   • Background Image (image)
   • Button Text (text)
   • Button URL (text)
5. Choose the Inline (Block) kind when creating the model
6. Click Save

Using an inline schema as a field

1. Edit any model (e.g., Page)
2. Click Add Field
3. In the field type dropdown, you will see your inline schemas listed alongside built-in types:
   • Hero Banner
   • Testimonial Card
   • Feature Block
4. Select one and configure the field (label, required, help text)

Now when editing records of that model, editors see a structured form for the inline component.

Nesting Components

Inline schemas can contain other inline schemas, allowing you to build complex layouts from simple pieces:

Feature Grid
  -- Heading (text)
  -- Features (array of Feature Card)
       -- Icon (image)
       -- Title (text)
       -- Description (textarea)

Page
  -- Hero (Hero Banner)
  -- Sections (array of Page Section)
       -- Section Type (select)
       -- Feature Grid (Feature Grid)
       -- Testimonials (array of Testimonial Card)
       -- CTA (CTA Section)

Common Patterns

Page Sections

Create reusable page sections that editors can mix and match:

Cards

Create consistent card layouts used across multiple models:

UI Elements

Create standardized, reusable UI components:

Inline Schemas in Flexible Fields

Inline schemas double as block types for the flexible field. When a flexible field is rendered, every block in the array is an instance of an inline-schema model (or a built-in block primitive) — same definition, just embedded inline rather than stored as a standalone record.

Two effects:

1. Adding fields to an inline schema adds them to every block of that type. A Hero model with headline, subheadline, and imageUrl becomes a Hero block with the same three fields available everywhere a Hero is used.
2. Restricting blocks to a subset. By default, every inline-mode model is available as a block. To restrict, set config.allowedTypes (alias: config.allowedBlockTypes) on the flexible field:

{
  "key": "body",
  "type": "flexible",
  "label": "Body",
  "config": {
    "allowedTypes": ["hero", "feature-grid", "testimonial-card"]
  }
}

Resolved shape

Each inline-schema block in a resolved flexible field is a typed block whose _type is the model key:

{
  "_type": "hero",
  "_id": "block-abc123",
  "headline": "Welcome",
  "subheadline": "...",
  "image": { "url": "https://...", "width": 1920, "height": 1080, "alt": "..." }
}

Field values are resolved through the normal pipeline — image fields return full ImageValue objects, references return resolved record data, and so on.

MediaBlock and ReferenceBlock

The platform registers two built-in block primitives that don’t need an inline-schema model:

• MediaBlock — embedded image/video/file. Resolved with the file’s full metadata (URL, dimensions, MIME type, and so on).
• ReferenceBlock — reference to another record. Resolves to a Record union you can type-narrow against your project’s models inline.

These primitives (along with the other built-in block types) handle the cross-cutting cases — media embeds and record references — so you don’t need a per-project inline schema for them.

Best Practices

• Keep components focused. Each inline schema should do one thing well.
• Use clear names. The name appears in the field type selector, so editors need to understand what each component is for.
• Add descriptions to help editors know when to use each component.
• Start simple and add fields as needed. Removing fields later is harder than adding them.
• Watch nesting depth. More than two or three levels of nesting can make the editing experience confusing.
• Use inline-only mode for components that should never exist on their own (buttons, badges, cards).