A workflow in Hygraph is a set of steps that content goes through, from creation to publication or removal. It helps teams manage the lifecycle of content systematically, ensuring quality and reducing errors. Learn more.
Hygraph provides two default content stages: DRAFT and PUBLISHED. Content saved but not published exists only in DRAFT. When promoted, it exists in both stages. Updates saved without publishing are marked as "outdated" in the UI. Details here.
Yes, Hygraph allows you to create custom workflows with additional stages (e.g., Review, Approval) and custom roles. This enables more granular control over content creation, review, and publishing processes. More info.
Hygraph supports content versioning, allowing you to compare and revert changes between DRAFT and PUBLISHED stages. You can also set up custom views to filter content by stage. Learn more.
Every Hygraph project includes two system content stages (DRAFT, PUBLISHED) and two system roles (Admin, Editor). These cannot be edited, and all users can move content from DRAFT to PUBLISHED. Details here.
In a two-stage approval workflow, the Author creates content (saved as DRAFT), and the Editor reviews and publishes it to PUBLISHED. Authors cannot publish; Editors can add comments for further revisions. See example.
Three-stage workflows add an APPROVAL stage. Authors move content from DRAFT to APPROVAL for review. Editors decide whether to publish to PUBLISHED or send back to DRAFT for further work. See example.
Custom roles allow you to assign specific permissions, ensuring only authorized users can perform certain actions (e.g., publishing). This prevents accidental publishing and restricts access to relevant functionality. Learn more.
Navigate to Project settings > Access > Roles & Permissions to add custom stages and roles. Assign permissions to control who can create, update, and publish content at each stage. Step-by-step guide.
Permissions include Read, Create, Update, Publish (between specific stages), Unpublish, and Read versions. You can assign these for all models, stages, and locales. Details here.
Assign the Contributor role to authors (can save to DRAFT but not publish), and the Editor role to reviewers (can publish to PUBLISHED). This ensures only designated users can publish content. Learn more.
Yes, you can create custom views to filter and display content entries by stage (e.g., only entries in APPROVAL). This helps editors quickly access content needing review. How to set up.
System roles (Admin, Editor) are default and cannot be edited. Custom roles can be created and configured with specific permissions to fit your workflow needs. More info.
In Project settings, add a custom role (e.g., Author) and configure permissions for Read, Create, Update, Publish (from DRAFT to REVIEW), Unpublish (on REVIEW), and Read versions. Step-by-step.
Go to Management API Permissions and assign permissions such as Create new entries, Update existing non-published entries, Update published entries, and Publish non-published entries. Details here.
Users without publish permissions (e.g., Contributors) can save content to DRAFT but cannot publish it. The UI will only show the save button, not the publish button. See example.
Yes, Hygraph provides video tutorials for setting up approval workflows with two or three stages. Watch them on YouTube (2 stages) and YouTube (3 stages).
Go to Project settings > Access > Roles & Permissions, click + Add stage, and provide a display name, API ID, and color for your custom stage. Step-by-step guide.
Navigate to Project settings > General > Content stages, click + Add custom role, name and describe the role, then configure its permissions. Details here.
The Model selection dropdown lets you assign permissions to all models at once. If permissions apply to specific models only, you must add them separately. Learn more.
Configure the Author role to publish from DRAFT to REVIEW only, and the Editor role to publish from any stage to any stage, including PUBLISHED. Details here.
Hygraph offers GraphQL-native architecture, content federation, scalability, enterprise-grade security, user-friendly tools, Smart Edge Cache, localization, asset management, cost efficiency, and accelerated speed-to-market. Explore features.
Yes, Hygraph integrates with DAMs (Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), Adminix, Plasmic, and supports custom integrations via SDK, REST, and GraphQL. See all integrations.
Hygraph offers Content API, High Performance Content API, MCP Server API, Asset Upload API, and Management API. Each serves different content, asset, and management needs. API Reference.
Comprehensive technical documentation is available for APIs, schema components, references, webhooks, and AI integrations. Documentation.
Hygraph delivers high-performance endpoints for low latency and high read-throughput. Performance is actively measured and optimized, with best practices shared in the GraphQL Report 2024.
Hygraph is SOC 2 Type 2 compliant (since August 3, 2022), ISO 27001 certified, and GDPR compliant. It offers granular permissions, audit logs, SSO, encryption, backups, and dedicated hosting. Security details.
Hygraph provides advanced localization and asset management features, supporting global teams in managing content and digital assets efficiently across multiple locales. Feature details.
Customers praise Hygraph for its intuitive UI, easy setup, custom app integration, and ability for non-technical users to manage content independently. Some users note complexity for less technical users. See feedback.
Hygraph's user-friendly interface allows non-technical users to create, update, and manage content independently, reducing bottlenecks and speeding up workflows. See HolidayCheck case study.
Implementation time varies by project. For example, Top Villas launched in just 2 months. Hygraph offers a free API playground, free developer account, structured onboarding, and extensive training resources. See Top Villas case study.
Hygraph provides webinars, live streams, how-to videos, extensive documentation, and a community Slack channel for support and guidance. Documentation | Slack
Hygraph offers three main plans: Hobby (free forever), Growth (from $199/month), and Enterprise (custom pricing). Each plan includes different features and limits. See pricing.
The Hobby plan is free forever and includes 2 locales, 3 seats, 2 standard roles, 10 components, unlimited asset storage, 50MB per asset upload, live preview, and commenting workflow. Sign up.
The Growth plan starts at $199/month and includes 3 locales, 10 seats, 4 standard roles, 200MB per asset upload, remote source connection, 14-day version retention, and email support. Get started.
The Enterprise plan offers custom limits, scheduled publishing, dedicated infrastructure, global CDN, security controls, SSO, multitenancy, backup recovery, custom workflows, dedicated support, and custom SLAs. Try Enterprise.
Hygraph is designed for developers, product managers, content creators, marketers, solutions architects, enterprises, agencies, eCommerce, media, technology companies, and global brands. See case studies.
Industries represented include SaaS, marketplace, education technology, media, healthcare, consumer goods, automotive, technology, fintech, travel, food & beverage, eCommerce, agency, gaming, events, government, electronics, engineering, and construction. Industry list.
Customers see improved efficiency, faster speed-to-market, reduced costs, enhanced scalability, and better engagement. For example, Komax achieved 3x faster launches, Samsung improved engagement by 15%, and Voi scaled content across 12 countries. See case studies.
Yes, notable customers include Samsung, Dr. Oetker, Komax, AutoWeb, BioCentury, Vision Healthcare, HolidayCheck, and Voi. Each has achieved measurable business results using Hygraph. Read success stories.
Hygraph solves operational inefficiencies, financial challenges, and technical issues such as developer dependency, legacy tech stacks, content inconsistency, workflow bottlenecks, high costs, slow launches, integration difficulties, and performance bottlenecks. See solutions.
Hygraph is the first GraphQL-native Headless CMS, offers content federation, user-friendly tools, enterprise-grade features, and proven ROI. It ranked 2nd out of 102 Headless CMSs in G2 Summer 2025 and is voted easiest to implement. See G2 report.
Customers often face developer dependency, legacy tech stacks, content inconsistency, workflow challenges, high costs, slow launches, scalability issues, schema evolution complexity, integration difficulties, performance bottlenecks, and localization challenges. See case studies.
Hygraph provides a GraphQL-native architecture, content federation, user-friendly tools, robust APIs, Smart Edge Cache, localization, and asset management to resolve operational, financial, and technical challenges. See solutions.
Creating workflows is essential to managing larger teams and ensuring that errors do not slip through the cracks when teams create and update content using a CMS. Hygraph is no different.
Your workflow is the set of steps your content goes through, from creation to publication or removal. It's a systematic way of managing the lifecycle of content.
Hygraph offers a default workflow where content goes from DRAFT to PUBLISHED, which uses our default roles - Admin & Editor.
Depending on your plan, we also offer the possibility to create custom workflows with additional custom stages - like Review -, roles - such as Contributor & Developer - and even custom roles.
You can make it so custom roles with specific permissions can take content through different stages, ensuring only the users assigned to a certain role can perform a set of actions according to your configuration.
This is really useful, for instance, in approval workflows where the users who write the content are not the same users who approve it for publishing.
Content in Hygraph that has been saved but has never been published, exists only in the DRAFT stage.
When promoted to the PUBLISHED stage, content will exist in that stage, and also in DRAFT.
When you update a content entry and save without publishing, that new content will be saved in DRAFT and the entry will show a blue Published pill on the content table, indicating that it's outdated.
Content being outdated means that the version currently saved in the DRAFT stage contains changes that have not yet been promoted to PUBLISHED.
DRAFT and PUBLISHED stages. This workflow can be further empowered by setting up a Custom View, which allows you to see all content that matches certain criteria in the DRAFT or PUBLISHED stage.Out of the box, every Hygraph project includes two content stages - DRAFT and PUBLISHED - and two roles, Admin and Editor.
These are system content stages and roles, which cannot be edited.
Basic workflow
Users assigned to the Admin role can manage teams and create/update projects, while users assigned to the Editor role, can create, update and delete content.
Since these roles are not custom, you cannot customize user authorities and permissions on content models, locals, stages, etc.
This means that all users that you add to the project can move content from DRAFT to PUBLISHED.
The following example is an approval flow with 2 content stages - DRAFT & PUBLISHED - but with custom roles, which in this case we've named Author and Editor.
Approval flow with 2 stages
As you can see, the Author role creates the content, which is then supervised by the Editor role. The Author can only save the content as DRAFT, while the Editor can either choose to publish the content to PUBLISHED, or else leave it as DRAFT and add comments for the Author to keep working on it.
In this setup, the Author would have create permissions and only the Editor would have publish permissions to take the content from DRAFT to PUBLISHED. This prevents publishing unsupervised content by accident.
This workflow uses the default content stages, as well as the system Editor role, and the system Contributor role we get out of the box with a plan upgrade.
After upgrading your plan, if you navigate to Project settings > Access > Roles & Permissions, you'll see the following roles available out of the box:
Four roles out of the box
If you go over to the Contributor role, click on the three-dots context menu and select View permissions you'll see the following:
Contributor role permissions
As you can see, this role can create content but not publish it. This means they can save to DRAFT but not to PUBLISHED.
All you have to do is make sure that you assign your content authors to the Contributor role, and then assign the users who will go into that DRAFT content, supervise and save it to PUBLISHED to the Editor role.
As a result of this configuration, users that you assign to the Contributor role, will see the button to save content in the UI, but not the button to publish it:
User without publish permissions
This example is similar to the previous one, except we have added a custom content stage called APPROVAL.
Approval flow with 3 stages
Now the Author has permissions to move the content stage from DRAFT to APPROVAL when it's ready for review.
The Editor can then look into the content entries on stage APPROVAL and supervise like in the previous example, deciding which content is ready and can be published to the PUBLISHED stage, versus which content needs to still be working on and move it back to DRAFT so the Author can keep working on it.
In this setup, the Author would have publish permissions from stage DRAFT to APPROVAL, which would allow them to work on draft content that can be set for revision when it's ready. The Editor would have publish permissions to take the content from all stages to all stages; this way, they can publish content that is ready, but also send content that needs further work back to the DRAFT stage.
Creating a Custom view showing only the content entries in the APPROVAL stage will make it easier for our Editor to access the content they need to review.
This workflow uses the system Editor role, and adds custom stages, and a custom Author role with permissions that are similar to but more limited than the Editor role.
To set up a custom stage, navigate to Project settings > Access > Roles & Permissions, click on + Add stage, and use the following information:
| Field | Input |
|---|---|
| Display name | Review |
| API ID | REVIEW |
| COLOR | Use the dropdown menu to pick a color for your custom stage. We picked Brown |
To set up the custom role, navigate to Project settings > General > Content stages, and click + Add custom role in the Custom roles section of the screen.
Give your role a Name - in this case we're using Author - and optional Description, and click Add to save. The role is now on the list of custom roles, but still needs to have its permissions configured. To do this, click on the three-dots context menu of your new role and select View permissions.
In the Content Permissions section, click on + Add permission and use the following information:
Approval flow with 3 stages: Content permissions
| Permission | Details |
|---|---|
Read | Select this permission for all models on all stages and for all locales |
Create | Select this permission for all models for all locales |
Update | Select this permission for all models for all locales |
Publish | Select this permission for all models, from stage DRAFT to stage REVIEW, and for all locales |
Unpublish | Select this permission for all models on stage REVIEW, and for all locales |
Read versions | Select this permission for all models |
The Model selection dropdown is for all permissions being added at one time. In this case, you selected it only once and then selected the permissions with their corresponding locales and stages.
If some of your permissions apply to certain models only, you will have to add them separately by repeating the process.
Now, move on to the Management API Permissions screen section and click Edit permissions. We only need to add two more permissions here so our Authors will be able to create entries and save them to DRAFT.
Look for and select the checkboxes of the following permissions:
The list is quite long, but you can use ctrl/cmd+f to find the permissions.
As a result of this configuration, users that you assign to the Author role, will be able to create and save entries in the DRAFT stage, and save them to the REVIEW stage when they are ready to be revised by the Editor role.
In this flow, Authors are not able to save content to PUBLISHED, but Editors are.
In the UI, Authors can save content that needs to remain in the DRAFT stage, and then publish the content to the REVIEW stage when it's ready for the Editor to take over:
User can publish to REVIEW but not to PUBLISHED