Roles and Permissions in GreenSphere

Access in GreenSphere works in two layers. Organization roles apply across the whole organization. Site roles apply inside a single site, and they're managed separately from the Site members area. An organization-level role can also grant inherited access to sites.

One rule sits underneath everything else: a site grant only works while the person is still an active member of the organization. Remove someone from the organization and every site-level grant they held stops working automatically — there's no stale access left behind.

Organization roles

Organization roles are set when you invite someone and can be changed from Settings. There are five, in descending order of authority — each role includes everything the role below it can do.

• Owner — for the main person accountable for the organization. Owners can do everything an Admin can, and they also control billing, plans, and ownership transfer. This is the only role with those last three.
• Admin — for trusted operators running the program. Admins manage members, sites, data, targets, and catalog setup (raw data types, indicators, emission factors).
• Editor — for day-to-day data owners. Editors can add and update data and targets. They cannot manage users, sites, or catalog setup.
• Contributor — for teammates who submit regular readings. Contributors can add new data and view the context they need. They cannot edit history or manage setup.
• Viewer — for teammates who only need visibility. Viewers can read data and reports. They cannot create, edit, or delete anything.

Organization permission matrix

What each organization role can do, by action. A check means the role has that permission directly or inherits it from a higher role.

Two things to read carefully:

• Contributors can add data but not change it. Entering a new reading is a Contributor action; editing or deleting an existing one is an Editor (update) or Admin (delete) action. This keeps a clean line between "submitted a reading" and "changed the record."
• Catalog setup is an Admin capability, bundled. Creating raw data types, indicators, and emission factors all sit with Admin. Editors run data day-to-day but don't shape the catalog those data points belong to.

Site roles

Site roles are managed per-site from the Site members area, not from the organization role picker. They apply only inside that one site. There are four.

• Site Viewer — for people who only need one-site visibility. They can read site data and configuration. They cannot make changes or access other sites.
• Site Contributor — for teammates submitting site readings. They can add new data for this site. They cannot edit history, change setup, or access other sites.
• Site Editor — for a local operator maintaining one site. They can edit site data and configuration. They cannot manage members or work outside the site.
• Site Admin — for the local owner of one site. They can manage local access, setup, and data. They cannot delete the site or affect other sites.

An organization role can also reach into sites: an org Editor, for example, carries editor-level access into the sites they can see, without needing a separate site grant. Site roles layer on top of that for people who need access to one specific site without a broad organization role.

Site permission matrix

What each site role can do inside its site. The final column shows what an organization-level role grants by inheritance.

The standout is the last row. A Site Admin cannot delete their own site. Deleting a site requires organization-level site authority, by design — it stops a local site owner from removing a site out from under the wider organization. Site Admins manage everything else inside the site; deletion is held one level up.

Three rules worth knowing

Beyond the matrices, three enforcement rules govern the trickier resources.

1. Deleting a site needs organization authority, not just site authority. As above — a Site Admin manages and updates the site, but deletion is reserved for organization-level site management. A direct site grant alone can never delete the site.

2. Targets, reports, and files need dual authority to delete. Reading and updating a target, report, or file follows the normal site/org editor path. Deleting one is stricter: it requires admin authority at both the site and the organization. A site admin alone can't delete it, and an org admin alone can't either — both have to be true. This is the same shape across all three resource types.

3. Audit-log entries are double-gated. Writing an audit-log entry for a data point requires update rights on that entry and data-entry rights at its site. That's deliberately stricter than either permission on its own, so the audit trail can't be written by someone who only half-qualifies.

What this guide doesn't cover

• Inviting team members and assigning their first role — that happens during onboarding and from Settings. (Cross-link to the team-invite guide when it ships.)
• Setting up sites — creating and configuring sites is its own workflow.
• Plan tiers — which roles or seat counts are available on which plan is a billing question, separate from what each role can do.

Where to go from here

Once you know who can do what, the natural next steps are setting up the sites your roles apply to, and reviewing the audit trail — the record that the permission rules above are designed to protect. For the data those permissions govern, see how emissions calculations work.