A stack is a container that holds all the content (entries) and assets related to a site. It also serves as a collaboration space where multiple users can work together to create, edit, approve, and publish content.
A content type lets you define the structure or blueprint of a page or a section of your web or mobile property. Content type consists of fields which are the building blocks for structured content. Using content types, you can create content of the same nature and pattern. Common examples of a content type are landing pages or blogs.
The Reference field allows you to create references to entries of the same content type or other content types. It lets you access and use entries of other content types as an input within your field. You can create references to the same content type (Self Referencing) or to other content types (Include Referencing).
A modular block is a field that allows users to dynamically create and modify components of a page or app on the go.
The developer first needs to add this field to the content type builder while creating a content type, and then add blocks with different sets of fields (say “Banner” with Single-line Textbox and Image fields, “Product Details” with Title, RTE, and Image fields, or “Video” with File and Multi-line Textbox fields) within each block.
When creating a new content entry, content managers have the option to choose from multiple blocks (“Banner,” “Product Details,” or “Video”). Content managers can add the required block or multiple blocks from these options, move blocks up or down, remove them, as and when needed.
For more flexibility in building a dynamic web page structure, you can nest Modular blocks within Global fields.
A Global field is a reusable field (or group of fields) that you can define once and reuse in any content type within your stack. Subsequently, when you use the Global field within any content type, the subfields would appear automatically.
Global fields allow you to manage these fields from one central location. So, if you update an existing Global field, the changes would reflect in all the content types in which the Global field is used.
To simplify the process of reusing different content schemas across several Modular Blocks, you can nest Global Fields within Modular Blocks.
An entry is the actual piece of content that you want to publish. You can create entries for one of the available content types. Before working with entries, it is essential to ensure that the required content types are in place.
Assets are any files stored in the system, such as images, videos, PDFs, audio files, and so on. Contentstack allows you to upload and store files in your assets repository for future use. Once you upload a file, it can be attached to any entry. This flexibility is especially useful when you want to use specific assets in multiple entries.
A publishing environment corresponds to one or more deployment servers or a content delivery destination (web page URLs) where the entries need to be published. When you publish content to an environment, the content displays at the destination URL. The most common publishing environments used are development, staging, and production.
Localization allows you to add multiple languages to your stack and publish your entries in multiple languages.
Tokens let you authorize API calls. There are two types of tokens:
- Management Token: Lets you make authorized Content Management API requests.
- Delivery Token: Lets you make authorized Content Delivery APIs. Delivery Tokens provide read-only access to the associated environments.
Once you create an entry/asset, you can publish it to one or all of the available publishing environments.
You can preview your entry before publishing it on the production environment of your website or app in a few simple steps. Another method of previewing your content is a two-step process that involves the creation of a Preview environment and then publishing content on this created environment.
By default, entry versions are identified with numbers (for example, Version 1, Version 2). However, you can assign a name to a version for easy identification (for example, Production Ready or Do Not Edit). Similarly, you can create versions for assets as well.
A Release allows you to pin together a set of entries and assets that needs to be deployed (published or unpublished) all at once to a particular environment.
For example, a product launch, press release, or sales promotion requires publishing large amounts of time-sensitive content, which is a daunting task.
A workflow lets you define the content creation and review process for your team. The core part of creating a workflow is defining the Workflow stages of content creation. Workflow causes content to flow through different stages before it is published.
For example, if you are defining a workflow, you might want your content to flow through the following stages:
In the above example:
- First Draft: The draft writing stage, where the content manager creates the first draft
- Review: A tech reviewer reviews the draft and makes required changes in the content
- Copyedit: Next, a proofreader checks the content for grammatical accuracy.
- SEO Tags: The SEO team will add SEO terms to increase the visibility of your content on the website in search engines
- Complete: The content is then marked as complete, and is ready for publishing
- Approved: An Approver approves the content for publishing
Once you have added these stages and enabled the workflow, the stages will be available for use on every entry page of the corresponding content types of the stack.
Whenever a person creates a new entry, for example, in the Draft stage, the user can work on this stage and push it to the next stage and assign it to a different user. The user can also assign a deadline (due date) for completion of the next task along with any special instructions if needed.
Publish Rules are like conditions that you define for your content publishing. They govern if entries can be published with or without someone’s approval or only when the content is at a particular stage.
To work on a stack, a user must be part of the Organization that contains the stack. A user cannot be directly invited to a stack without also being invited to an Organization. Each user can be assigned an Organization role as well as a Stack role.
In Organizations, three predefined roles are available that can be assigned to a user: "Owner,” “Admin,” and “Member”.
Contentstack provides four stack roles that can be assigned to a user. The predefined set of stack roles are “Owner,” “Admin,” “Developer,” “Content Manager,” and “Custom Role.”
The Organization Owner owns the Organization (and the subscription plan) in Contentstack. The Owner has maximum privileges, which includes the ability to:
- Invite users to Organizations and stacks
- Assign roles to users
- Set up SSO for an organization
- Transfer ownership of an Organization to another user
- Access stacks created by themselves
- Access to other users’ stacks, if adequate permissions are assigned by the owner of the stack
- Delete stacks of the Organization
Creating a stack in Contentstack makes you the Stack Owner of the stack. Each stack can have only one Owner, who has complete rights to the content and settings of a stack in addition to the combined rights of a “Developer” and a “Content Manager.” The Owner also can delete a stack as well as transfer the ownership of the stack to another user.
A user with the Organization Admin role has all the rights that the Owner enjoys, except access to billing details and the right to transfer ownership. The permissions for this role include:
- Inviting other users to organization and stacks
- Assign Admin or member role to other users
- Access stacks created by self
- Access to others’ stacks, as per the permissions defined by the owner of the stack
The Stack Admin role has the following rights:
- Create, update, delete, publish, unpublish entries and assets
- Create, update, delete languages, environment, content types and custom roles
- Invite users to and remove users from the stack
- View audit logs and publish queue
The Admin role has more rights than a Developer and fewer than the Owner. To know the difference, refer to the Stack Admin vs. Stack Owner section.
The rights of the Organization Member role can be modified by the Owner or the Admin user. The user with the Member role does not have access to the Organization Settings panel. Therefore, details such as Organization info, usage metrics, and so on are not visible to this user. The rights of this role include:
- Specific rights to stacks as assigned by the Owner or Admin
A Developer is a person who creates the structure of the site or defines the way content will appear on the site. This role has the following permissions:
- View Audit logs
- Create Roles
- Invite users
- Create/edit/delete languages, environments, and content types
- All the rights of a Content Manager
To know the difference between the Admin and Developer roles, refer to the Stack Admin vs. Stack Developer section.
A Content Manager is a user who works on the content of a stack. Thus, this role has the following rights:
- View content types
- Create and publish entries and assets
- View publishing queue
In addition to the predefined system roles (“Admin,” “Developer,” and “Content Manager”), you can add custom roles by defining specific permissions, and assign this role to the users of a stack. The best part about custom roles is that you have fine-grained control over permissions. You can assign permissions at the entry, field, and asset level. For example, the “ABC” role can READ only two entries of a content type, or EDIT only the SEO fields, or cannot READ any assets.
Trash is a container that temporarily stores deleted data (Content Type, Global Fields, Entries, and Assets). Using Trash, you can check what was recently deleted in your stack and recover those deleted items with ease.
Key Developer Topics
Learn about the hierarchy of entities and the fundamental concepts of Contentstack.
API stands for an application programming interface. APIs let you retrieve and deliver data to a web page or app. Contentstack is an API-first CMS platform, which means that it provides REST and GraphQL APIs that help you to query and manage your content.
Contentstack has four sets of APIs:
- Content Delivery API: Lets you retrieve content from Contentstack to display in your web applications and other digital devices
- Content Management API: Lets you manage and publish your content in Contentstack
- GraphQL Content Delivery API: Lets you fetch a customized response of both published and unpublished content using GraphQL
- Image Delivery API: Lets your retrieve, manipulate, and deliver images to your digital property
A webhook is a user-defined HTTP callback. It is a mechanism that sends real-time information to any third-party app or service. It helps you keep your application in sync with your Contentstack account.
Webhooks allow you to specify a URL to which you would like Contentstack to post data when an event happens. You can add webhooks for almost all the events in Contentstack.
Webhooks and APIs
The two most common ways to connect Contentstack to other systems are:
- To deliver information FROM Contentstack into another system, you would achieve this through use of a webhook
- To deliver information TO Contentstack from another system, you would make use of a content management API
Experience Extensions let you extend Contentstack’s UI by allowing you to integrate third-party applications into Contentstack. It enables developers to create customized experiences by augmenting Contentstack’s default UI and behavior.
You can create three types of experience extensions within Contentstack:
Contentstack provides prebuilt extensions for you to use in your content types. You can select and use any extension from this list. You can also create a custom extension either by writing the code directly in the Contentstack’s repository or by hosting it at a URL of your choice and providing the URL when configuring your extension in Contentstack.