Concepts

Paragraph CMS becomes much easier to model and operate when the team shares the same vocabulary. The core model starts with the workspace, then layers permissions, collections, pages, language variants, and labels on top of it.

Workspace and organization

In the product, the top-level container is the workspace. In the schema, that boundary is the organization.

A workspace owns the operational context for everything else:

• members, invitations, teams, and roles;
• active locales and the base locale;
• collections, pages, labels, statuses, and media; and
• billing, plan limits, and API keys.

This matters because Paragraph CMS does not treat localization, permissions, and content as separate systems. They all live inside the same workspace boundary, which keeps governance predictable as the content surface grows.

Teams

Teams are workspace-level access groups for people, not content types.

Their main job is to control who can work on which content streams. In the schema, collections store teamIds, which means access can be configured collection by collection. That lets one workspace support multiple teams without turning everything into one shared editorial backlog.

Use teams when different groups should work inside the same workspace but should not all have the same collection access.

Collections

Collections group related pages.

This is the cleanest way to think about them operationally: a collection is a bucket of pages that belong together because they share ownership, structure, or purpose.

Examples:

• blog posts;
• landing pages;
• case studies; or
• product marketing pages.

In the schema, a collection belongs to one workspace and can define:

• a name and description;
• a default data model; and
• which teams can access it.

That default data model is useful when pages in the same collection should start from the same structured field set. In other words, collections do not just organize pages visually. They can also shape how those pages are modeled and who is allowed to work on them.

Pages

Pages are the main content records editors create and maintain.

A page stores the actual editorial payload:

• title;
• hero;
• content;
• structured custom fields;
• status, author, reviewer, and publish date;
• slug and SEO metadata; and
• the page language.

Pages can belong to a collection, and they can also point to a specific data model. That makes a page both an editorial document and a structured content object.

Language variants

The most important detail is that Paragraph CMS treats multilingual pages as one page identity with multiple language variants.

In the schema, this works through page_translation_group:

• each language variant is its own row in page;
• all variants of the same page share one translationGroupId; and
• each language can exist only once per translation group.

That means one page can have an English, Polish, German, and French variant without losing the fact that they all represent the same underlying page.

Operationally, this is much cleaner than duplicating pages manually. Editors work with one page group, then move between its language variants.

One-click translation

When a language variant does not exist yet, Paragraph CMS can create it in two ways:

• copy the current variant; or
• translate it with AI in one action.

The translation flow covers more than the body content. It also translates:

• the page title;
• SEO meta title and meta description;
• rich text or markdown/html content;
• supported structured fields; and
• inline image metadata such as alt text, image title, and image slug.

The new page variant then gets its own slug, generated from the translated title, so each locale can resolve to a locale-appropriate URL. Existing variants can also be retranslated from the current source variant.

This is why localization in Paragraph CMS is not just “copy the page and translate later.” The system preserves the relationship between variants and automates the parts that usually become manual editorial work.

Media and localized image metadata

Media is part of the content model, not a side system.

Pages can reference media inside their content, and Paragraph CMS keeps image metadata close to the editorial workflow. During page translation, inline image metadata can be localized per language variant. That is especially useful for SEO, because the same visual can carry different locale-specific descriptions and slugs across translated page variants.

Labels

Labels are workspace-level tags for pages.

In the schema, labels are attached through the page_label join table, which means:

• one page can have many labels; and
• one label can be reused across many pages.

Use labels for lightweight classification such as:

• categories;
• campaign markers;
• SEO flags;
• content themes; or
• internal workflow markers.

Labels are different from collections. A collection is the primary grouping container for pages. A label is an overlay used for categorization, filtering, and editorial organization.

Locales

Locales are configured at the workspace level.

Each workspace has a base locale and a list of active locales. That list defines which language variants can be created inside the workspace and keeps localization rules consistent across all collections and pages.

This makes multilingual publishing a system capability, not an ad hoc page-by-page convention.

How the model fits together

In practice, the content model looks like this:

1. a workspace defines the people, permissions, and active locales;
2. teams limit access to specific collections;
3. collections group related pages and can provide a default model;
4. pages hold the actual content and SEO data; and
5. labels add flexible categorization across pages.

That structure is what gives Paragraph CMS its operating model: organized page inventories, real multilingual variants, collection-level access control, and reusable editorial classification without losing simplicity.