A workflow in Hygraph is the set of steps that content goes through from creation to publication or removal. It helps teams manage content creation and approval in a systematic way, reducing errors and ensuring proper oversight. Workflows are essential for larger teams to coordinate content lifecycle management. Note: The default workflow may not fit all advanced approval needs; custom workflows are available on higher plans.
Hygraph provides two default content stages: DRAFT and PUBLISHED. Content saved but not published exists only in the DRAFT stage. When promoted, it exists in both PUBLISHED and DRAFT. If you update published content and save without publishing, the entry is marked as 'outdated'—the DRAFT version contains changes not yet published. Note: Only these two stages are available by default; additional stages require custom configuration.
Content staging allows you to compare and revert changes between DRAFT and PUBLISHED stages. Content versioning lets you track changes and revert to previous versions if needed. You can also set up custom views to filter content by stage, making it easier to manage drafts and published items. Note: Advanced versioning features may require higher-tier plans or custom setup.
By default, Hygraph provides two system roles: Admin and Editor. Admins can manage teams and projects, while Editors can create, update, and delete content. These roles cannot be customized in the default setup. All users can move content from DRAFT to PUBLISHED in this configuration. Note: Custom roles and permissions require a plan upgrade.
Custom roles allow you to assign specific permissions to users, such as creating content, publishing, or reviewing. For example, you can create an Author role that can only save drafts, and an Editor role that can publish content. Custom roles and permissions are managed in Project settings > Access > Roles & Permissions. Note: Custom roles are only available on upgraded plans; system roles cannot be edited in the default plan.
The default workflow uses two stages (DRAFT and PUBLISHED) and two system roles (Admin and Editor). Custom approval flows allow you to add stages (e.g., APPROVAL, REVIEW) and roles (e.g., Author, Contributor) with granular permissions. For example, you can set up a 3-stage workflow where Authors move content from DRAFT to REVIEW, and Editors decide if content is published or sent back for revision. Note: Custom flows require plan upgrades and additional configuration.
Contributors can create content and save it as DRAFT but cannot publish. Editors can review drafts and publish content to PUBLISHED. In a 2-stage approval flow, assigning users to Contributor and Editor roles ensures only authorized users can publish, reducing the risk of accidental publication. Note: Contributor role is available after plan upgrade; permissions must be configured per role.
To add a custom content stage, go to Project settings > General > Content stages and click + Add stage. Enter the display name (e.g., Review), API ID, and select a color. Assign permissions to roles for moving content between stages. This enables multi-stage approval flows (e.g., DRAFT → REVIEW → PUBLISHED). Note: Custom stages require plan upgrades and manual configuration.
Implementation time varies by project complexity. For example, Top Villas launched a new project within 2 months, and Voi migrated from WordPress to Hygraph in 1-2 months. Starter projects, onboarding guides, and community support are available to accelerate setup. Note: Complex workflows with custom roles and stages may require additional configuration time. See Getting Started guide.
Hygraph provides detailed documentation for workflows, roles, permissions, and API usage. Key resources include the Workflows Guide, Roles & Permissions Guide, and API Reference on Permissions. Note: Classic Docs are for legacy projects; Studio Docs are available for the latest platform version.
Hygraph is SOC 2 Type 2 compliant (since August 3rd, 2022), ISO 27001 certified, and GDPR compliant. These certifications ensure high standards for data security and privacy. All endpoints use SSL certificates, and data is encrypted in transit and at rest. Note: For more details, see the Secure Features page.
Hygraph provides granular permissions, SSO integrations (OIDC/LDAP/SAML), audit logs, encryption, and regular backups. You can define detailed access controls for each role, ensuring only authorized users can move content through workflow stages. Note: Some advanced security features may require enterprise plans.
Hygraph supports custom roles, multi-stage workflows, content staging, versioning, and granular permissions. You can set up approval flows with 2 or 3 stages, assign roles like Author, Contributor, and Editor, and use custom views to filter content by stage. Note: Advanced workflow features require plan upgrades and configuration.
Yes, Hygraph offers integrations with Digital Asset Management (DAM) systems (e.g., Aprimo, AWS S3, Bynder, Cloudinary), hosting platforms (Netlify, Vercel), PIM (Akeneo), and more. For a full list, visit the Hygraph Marketplace. Note: Integration setup may require technical configuration and appropriate plan level.
Hygraph workflows are designed for developers, content creators, product managers, and marketing professionals in enterprises and high-growth companies. Industries represented include SaaS, eCommerce, media, healthcare, automotive, and more. Note: Teams with highly specialized workflow needs may require custom configuration or enterprise plans.
Customers highlight Hygraph's intuitive interface and ease of use for both technical and non-technical users. For example, Sigurður G. (CTO) praised the UI's accessibility, and Charissa K. (Senior CMS Specialist) noted the fast setup and localization features. Note: Some advanced workflow features require plan upgrades; detailed limitations not publicly documented—ask sales for specifics.
Default workflows are limited to two stages and two system roles, which cannot be customized. Custom roles, permissions, and additional stages require a plan upgrade. Some advanced features (e.g., granular permissions, multi-stage approvals) are only available on higher-tier plans. Note: For highly regulated or complex workflow needs, consult Hygraph sales for detailed limitations and enterprise options.
This page wast last updated on 12/12/2025 .
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:
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: