Granular permissions in Hygraph allow administrators to define highly specific access controls for users, permanent auth tokens, and public API access. This means you can restrict visibility and access down to a single content entry, model, stage, locale, or even specific actions like publish or unpublish. These permissions can be tailored for both internal and external collaborators, ensuring that each user or token only has the rights necessary for their role. Source
How do custom roles work in Hygraph?
Custom roles in Hygraph let you define permission sets tailored to your organization's needs. You can create roles such as Translator, Shop Owner, or Partner, and assign them specific permissions for actions (read, create, update, delete, publish, unpublish) on particular models, stages, and locales. Custom roles can be created and managed via both the UI and API, and are available to Owners and Admins by default. Source
What are system roles in Hygraph and what permissions do they have?
System roles in Hygraph are predefined roles that come with default permission sets. These include Owner (admin plus billing and project deletion), Admin (developer plus team management and project updates), Developer (editor plus model and enum management), Editor (contributor plus content deletion), and Contributor (can create and update content). These roles help structure access and responsibilities within your project. Source
How can permissions be scoped in Hygraph?
Permissions in Hygraph can be scoped to specific actions (such as publish, unpublish, read, create, update, delete), models (like page or post), stages (draft, QA, published), locales, and even conditions (e.g., only unpublish docs in fr_CA if the title contains "Checkout"). This allows for highly flexible and secure access management across your content and teams. Source
How does Hygraph handle permissions for models with relations?
When setting permissions on models with relations, Hygraph requires that users have the necessary permissions on both related models to perform certain actions. For example, updating a Post to add or remove a Category requires update permissions on both the Post and Category models. This ensures data integrity and secure access across related content. Source
Where can I learn more about setting up custom roles and permissions in Hygraph?
What are the benefits of Hygraph's granular permissions?
Hygraph's granular permissions system allows organizations to model their internal structures and business logic precisely. Benefits include enhanced security, the ability to restrict access for internal and external collaborators, protection of sensitive content, and the flexibility to create custom roles for specific tasks (e.g., translators, SEO auditors). This ensures that users only have access to the content and actions they need, reducing risk and improving workflow efficiency. Source
Does Hygraph support field-level permissions?
As of the latest update, field-level restrictions are planned for a future release and are not yet available. Currently, permissions can be scoped to models, actions, stages, locales, and conditions. Source
Can permissions be set for public API access and permanent auth tokens?
Yes, all permissions in Hygraph can be associated with a particular environment and can be created for both Public API Permissions and Permanent Auth Tokens. This allows for secure and controlled access to your content via APIs. Source
Security & Compliance
What security and compliance certifications does Hygraph have?
Hygraph is SOC 2 Type 2 compliant, ISO 27001 certified, and GDPR compliant. These certifications ensure enterprise-grade security and data protection for all users. Hygraph also offers features like SSO integrations, audit logs, encryption at rest and in transit, and sandbox environments. For more details, visit the Hygraph Security Features page.
Getting Started & Support
How can I get started with Hygraph?
You can get started with Hygraph by signing up for a free-forever account at app.hygraph.com. Comprehensive documentation, onboarding guides, and video tutorials are available to help you set up and use the platform effectively. Hygraph Documentation
What support is available for setting up permissions and roles?
Hygraph offers 24/7 support via chat, email, and phone. Enterprise customers receive dedicated onboarding and expert guidance. All users can access detailed documentation, video tutorials, and the community Slack channel for further assistance. Hygraph Contact Page
Product Information & Use Cases
What is the primary purpose of Hygraph?
Hygraph's primary purpose is to unify data and enable content federation, empowering businesses to create impactful digital experiences. Its GraphQL-native architecture removes traditional content management pain points and offers scalability, flexibility, and efficient data querying. Source
Who can benefit from using Hygraph?
Hygraph is designed for developers, IT decision-makers, content creators, project/program managers, agencies, solution partners, and technology partners. It is especially beneficial for modern software companies, enterprises looking to modernize their technologies, and brands aiming to scale across geographies or improve development velocity. Source
What are some real-world examples of Hygraph's granular permissions in action?
One example is setting up a custom role for a Canadian-French docs writer, where permissions allow reading docs in all stages for both English and fr_CA locales, but only creating, updating, and deleting docs in fr_CA. Additionally, the role can only unpublish docs in fr_CA if the title contains "Checkout." This demonstrates the flexibility and precision of Hygraph's granular permissions system. Source
Pricing & Plans
What is Hygraph's pricing model?
Hygraph offers a free forever Hobby plan, a Growth plan starting at $199/month, and custom Enterprise plans. For more details, visit the pricing page.
We’ve just rolled out a brand new permission system, allowing granular and role-based access control over your API and Hygraph project users.
+3
Written by Larisa, Jonas, Pablo & 2 more
on Jul 01, 2021
We’re excited to share that we have made some considerable improvements to the way Hygraph handles permissions for users, permanent auth tokens, and public API access. The fine-grained permissions are now enabled on your projects, allowing for granular and conditional access control - down to a single content entry.
TL;DR
We're rolling out a highly granular permission system that allows you to model your organizational structures and application business logic.
Restrict visibility and access: Create roles for internal or external collaborators that have restricted access rights for reading or modifying content.
Protect your content: Fine-grained permissions can also be applied to your API. Allow different content sets to be seen for authorized users.
Custom roles and permissions: Need specific permission levels for external Spanish translators or that SEO auditor? Set up custom roles to perform exactly those functions. Nothing more, nothing less.
Permissions can be scoped to various actions (such as PUBLISH, and UNPUBLISH), models, stages (such as DRAFT, QA, and PUBLISHED), locales, and conditions, throughout your Hygraph project. Field level restrictions will be introduced in a future release.
Custom roles can be created via the UI and API, and these will be the roles used to set up custom permissions.
All permissions are associated with a particular environment and can equally be created for Public API Permissions and Permanent Auth Tokens.
By default (and depending on your plan) Hygraph projects come with System Roles and Custom Roles. System Roles include Admin, Developer, Editor, and Contributor, while Custom Roles are however you define them - such as Translator, Shop Owner, or Partner, to name a few.
Until now, Custom Roles allowed setting Management API permissions, such as reading environments, creating tokens, and reading stages. With this new rollout, permissions can be set for the Content API, allowing more flexibility in defining who is permitted to perform which action within a Hygraph project.
System Roles
The system roles remain the same.
Owner: Admin + Ability to change billing and to delete projects
Admin: Developer + Ability to manage teams and create, update projects.
Developer: Editor + Ability to create, update and delete models and enums.
Editor: Contributor + Ability to delete content.
Contributor: Ability to create and update content.
Custom Roles
To create and update custom roles, a user must have Management API permissions to Create New Roles and Update Existing Roles. Owners and Admins of a project have this permission set by default.
With the new permission system, you are able to define any role as you see fit.
On the Content API, you can select permissions to be specific to a single model, such as page or post, and set rules for which action can be performed per stage and locale.
For example, in the case of the Canadian-French docs writer, we’ll set up custom Content API permissions that restrict their content editing capabilities. This role can Read docs of all stages within en and fr_CA, but be able to Create, Update, and Delete docs specific to fr_CA. Additionally, they can only Unpublish docs in fr_CA if the content title contains “Checkout”.
Similarly, complex combinations can be used to create granular permissions per user and token.
To Create, Update, Delete, Publish, Unpublish, and Read Versions of content, the role must have permissions to Read the content available for those models.
Permissions and Relations
When setting up permissions on models with relations, special consideration must be taken, as permissions might be required on both models to perform certain actions. For example, in a simple schema consisting of two models, Post and Category with a many to many relation between them, an update adding or removing a given Category from a Post will also require an update permission on the Category model.
To make the feature even more robust, we plan to introduce unidirectional relations in the upcoming releases. Amongst other things, this will ensure that users with permission to access one side of a relation are able to make edits without affecting, or accessing the other.