What are Permission Groups?

In CloudCannon, permissions control what actions your team members can perform within your Organization. The Permission Groups a team member belongs to determine their permissions.

A Permission Group defines a set of permissions for each member of that Group. Every team member in your Organization must be a member of at least one Group. When you invite a team member to your Organization, CloudCannon will prompt you to select a Permission Group to add them to.

All Permission Groups consist of a list of resources and the scopes those resources apply to.

• Resource — Something you can interact with in CloudCannon. A resource could be an individual Site, Pull Request settings, billing information, and more.
• Scope — Define how broadly a permission is applied. There are five levels of scope (Global, Project, Site, Group, and Base Domain). How many levels of scope are available will depend on whether you are using Default or Custom Permission Groups.

Each resource in a Permission Group has one or more associated actions: Read, Write, or Create.

• Read — The capacity to see a resource and open it to view its contents. Read is the most basic level of a resource. If you do not have Read for a particular resource, that resource will not appear in your CloudCannon interface.
• Write — The capacity to edit a resource. If you have Write for a particular resource, CloudCannon will automatically allow you to Read.
• Create — The capacity to create more instances of a resource. Create only applies to a few resources. When you create an instance of a resource, CloudCannon will automatically give you permission to Read and Write that instance.

Let’s walk through an example.

The Default Permission Group Editors contains the permissions for site:write and site:create, both with a Global scope. Members of this Permission Group can open and edit any Site in this Organization (because permission to Write includes permission to Read) and create new Sites that they can then edit.

The Editors Group does not contain the permission site:source-editor:read, which means members of this Group cannot open any files in the Source Editor. The option to open a file in the Source Editor will not appear in the CloudCannon interface, including in:

• The file Context menu in the file browser and editing interface.
• The Interface buttons at the top right of any editing interface.

For a complete list of resources and their associated actions, please read our reference documentation on permissions.

Default Permission Groups#

CloudCannon provides several Default Permission Groups on all pricing plans, including four Groups with Global scope (Owners, Developers, Technical Editors, and Editors) and another three Groups per Site with Site scope for Site Sharing and Client Sharing. Each of these Groups has a defined set of permissions so that you can select the appropriate level of control for each team member.

You cannot edit the resources or scope of Default Permission Groups. Members of the Owners or Developers Permission Group can invite team members to your Organization and update which Permission Group team members belong to.

For more information, please read our documentation on Default Permission Groups.

Custom Permission Groups#

For Team and Enterprise plan customers, CloudCannon allows you to create Custom Permission Groups. Custom Permission Groups give you fine-grained control over the permissions in your Organization.

Using Custom Groups, you can add multiple permissions to a Group and alter the scope of each permission from Global to Project, Site, Group, or Base Domain. You can also define file globs and exceptions for each Group for more precise permissions.

For more information, please read our documentation on Custom Permission Groups.

Multiple Permission Groups#

You can be a member of multiple Permission Groups.

Permission Groups are always additive. In other words, permissions from one Group do not negate permissions from another. CloudCannon will allow an action if a team member has permission from at least one source.

Let’s walk through an example.

Heather is a member of Permission Group A, allowing her to access the Source Editor editing interface. She is also a member of Permission Group B, which does not include permission to use the Source Editor. In this example, CloudCannon will allow Heather to use the Source Editor because she has permission to do so as a member of Permission Group A.

The additive nature of Permission Groups is less relevant for Default Permission Groups, as all Default Groups are hierarchical (meaning that each Group also contains the permissions of all Groups below it in the hierarchy). However, for Custom Permission Groups, this also extends to any exceptions defined in a Group. If one Group allows an action, an exception in a second Permission Group does not prevent access to that resource.

Partner Permission Groups#

The CloudCannon Partner Program allows agencies or freelancers specializing in web design/development to set up their clients in CloudCannon.

CloudCannon will automatically add Owners from a Partner Organization to their Client Organizations as members of a special Partners Permission Group. Partner Organization Owners can add team members to a Client Organization, allowing them to give developers from their agency access to their Client's Sites.

Partner Organization members in a Client Organization do not contribute to the maximum number of team members allowed per Organization and, therefore, do not affect billing for the Client Organization.