Concepts

Paragraph CMS stays easier to operate when everyone on the team uses the same vocabulary. These are the concepts that matter most when you start designing content models, workflows, and front-end integrations.

Workspace

A workspace is the top-level environment where your team models content, manages locales, assigns permissions, and publishes entries.

Use one workspace when the same team, governance rules, and delivery model apply across surfaces. Split workspaces only when operations, ownership, or environments are materially different.

Pages and collections

Paragraph CMS separates route-driven content from reusable content.

• pages represent content that resolves to a URL or a route in your application;
• collections store reusable content such as authors, categories, navigation items, SEO defaults, or shared callouts.

This split keeps page rendering predictable while still allowing content reuse across multiple surfaces.

Entries

An entry is one concrete instance of a page or collection item.

Examples:

• one landing page;
• one blog post;
• one author profile; or
• one shared FAQ item.

Your front end usually renders entries, while editors think in terms of creating, reviewing, and publishing them.

Fields and blocks

Fields define the structure of an entry. They can be simple values like text, booleans, dates, or references, but they can also describe richer editorial building blocks.

Use fields for stable data contracts such as:

• title;
• slug;
• excerpt;
• SEO metadata; and
• author relationships.

Use blocks when editors need flexible page composition without inventing a new page type for every layout variation.

References and reuse

References connect entries together. They are how one article points to an author, a category, related posts, or a reusable CTA.

This is one of the main scaling mechanisms in Paragraph CMS. Shared entities should be modeled once, referenced many times, and updated centrally.

Locales

Locales let one content model support multiple markets or languages.

The operational goal is not to duplicate everything. It is to keep shared structure intact while allowing controlled overrides for fields that genuinely need local variation.

Draft and published states

Editorial flow depends on separating work in progress from public output.

• drafts support internal writing, revision, and preview;
• published entries represent the version that delivery APIs and production sites should expose.

This boundary is what allows teams to review content safely without leaking unfinished work.

Media

Media assets are part of the content system, not an afterthought. Images, files, and visual variants should be treated as reusable editorial assets with predictable usage rules.

That matters most when many pages, locales, or campaigns depend on the same asset inventory.

Roles and governance

High-volume publishing breaks down when every user can do everything.

Roles, approvals, and review boundaries make it possible to scale:

• who can draft;
• who can review;
• who can publish; and
• who can change the underlying content model.

Delivery model

Paragraph CMS does not assume one front-end stack. Your application decides how content is fetched, rendered, cached, previewed, and revalidated.

That means the CMS owns structure and workflow, while your front end owns presentation and runtime behavior.