Platform terminology

Organizations collate billing for multiple projects, which may be queried by the same or unique frontends.

An organization is an entity where multiple projects are grouped to give them a single billing point. It does not need to be a registered company.

Project configuration cannot be shared across projects in an organization, nor can its content be referenced across projects.

A member may be a member of multiple organizations but must be invited to each. The roles in each project are created uniquely.

Organizations are also where Single Sign-On (SSO) is configured so that members can register to your projects using the provider of your choice.

Splitting a Sanity implementation across organizations is almost never required. Only if you require different projects to be billed with different payment methods.

Datasets inside a project can reference one another, be used independently by members, and be queried by one or many API consumers.

A project is a siloed collection of datasets, members, and configuration options such as webhooks and tokens. These cannot be shared between projects. A member in one project is not automatically granted access to any other, though an administrator member may invite them.

All administrator members in a project will have access to project-level configurations such as datasets, members, tokens, custom access control, and webhooks. Other members may get read-only or no access to these.

Your various frontends and the Sanity Studio can be configured to query from or write data to multiple projects.

However, content cannot be referenced between projects, only between datasets.

With plugins and scripts, it is possible to migrate content across projects.

Dividing how you use Sanity across projects is useful when you need absolute separation of developer and author teams with very different content creation goals.

Think of the Sanity Studio as just one of the many frontends that interact with Content Lake API’s

A dataset is a collection of schemaless data stored as JSON and uploaded file and image assets. Members may have access to all datasets in a project by default, but their privileges can be filtered in each dataset using custom access controls.

Your applications can query data from multiple datasets, and your Studio can be configured to switch between them using workspaces. Content can be referenced between datasets using cross-dataset references.

Datasets are often used as “environments.” Many teams have dataset names mapped to development, staging, and production environments.

Predominately in Sanity, multi-tenant configurations are performed by separating content between datasets. You may have individual datasets for teams, brands, or markets, in addition to datasets as global sources of truth, which all other datasets may reference.

A project member may have a different view, create or edit permission depending on document values and dataset tags.

Members in Sanity can be active across multiple organizations and projects – but will need to be invited to any of them to begin collaborating and have unique roles within each. Their roles in a project will determine their access to datasets.

Members may be invited to a Sanity project via our built-in authentication or with Single Sign-on (SSO) configured, the provider of your choice.

They can be privileged as administrators to have complete access to all project settings and the ability to modify any data. Using custom access controls, permissions can be scoped to no access. Or, at a minimum, view-only permissions of a single document based on any value within it.

Example: A member with the custom role “Junior Store Manager” may only be able to view documents of the type product with a price field greater than 100 on the production dataset.

For projects with multiple teams or lines of responsibility, member roles ensure that individual content creators and developers do not have their work disturbed unexpectedly.