# Roles & Permissions

> Decide exactly what each collaborator can do on your project — build, publish, edit marketing, or manage money and infrastructure.

Source: https://knowledge.estage.com/project-settings/roles/
Part of the ESTAGE knowledge base (https://knowledge.estage.com). Full corpus: https://knowledge.estage.com/llms-full.txt

---
A **role** decides what a collaborator can do once they're in your project. Someone brought in
to write blog posts doesn't need access to your payment processing, and a developer working on
the site doesn't need to see your captured leads.

Roles are set in **Project Settings → Roles**, and assigned in **Project Settings → Members**.
They're **enforced on the server**, not merely hidden in the interface — a role that can't reach
payment processing can't reach it by any route.

## Built-in roles

Every project starts with three roles. You can use them as they are, edit them, or add your own.

| Role | Best for | What they can do |
| --- | --- | --- |
| **Admin** | A partner or lead developer you trust with everything | Everything except the owner-only actions below |
| **Contributor** | Someone building the site with you | Build, edit and publish. Sees payments, connectors and code injection but can't change them |
| **Marketer** | SEO, ads and content | SEO, Marketing Tags, Analytics, Autoresponders, the blog, funnels and audiences — and can publish those changes |

New invitations default to **Contributor**. You can pick a different role while inviting, or
change it later.

### What each one covers

<details>
<summary><strong>Contributor</strong></summary>

- **Building** — AI chat, visual editor, adding and removing pages, Image Studio, reverting a turn
- **Publishing** — the website and the web app
- **Settings, full access** — General, Business Details, Modules, SEO, Marketing Tags, Analytics,
  Languages, Global Variables, AI Assistant, Recaptcha
- **Settings, view only** — Payment Processing, Connectors, Code Injection, Security, Autoresponders
- **Blog** — posts, categories and authors
- **View only** — Marketing Funnels, Audiences, Members, Dedicated Cloud, Server

</details>

<details>
<summary><strong>Marketer</strong></summary>

- **Settings, full access** — SEO, Marketing Tags, Analytics, Autoresponders
- **Settings, view only** — General
- **Publishing** — the website, so an SEO or pixel change can actually go live
- **Blog** — posts, categories and authors
- **Marketing Funnels** — the whole module, including captured leads, AI generation and audits
- **Audiences** — view, edit and generate variants
- **View only** — Members

</details>

<details>
<summary><strong>Admin</strong></summary>

Everything in the project except the owner-only actions. Admin is defined as *"the owner, minus a
few things"*, so when Estage ships a new feature an Admin gets it automatically.

The narrower roles work the other way round — they're defined as an explicit list, so a new
feature is **not** silently granted to a Contributor or a Marketer. Somebody has to decide to add
it. That's deliberate: growing access should be a choice, not a side effect of an update.

</details>

## What only the owner can do

Some things stay with the project owner no matter what role you hand out:

| Action | Why |
| --- | --- |
| Delete or transfer the project | It's the owner's project |
| Invite people and change their roles | Granting access is how someone would grant themselves more of it |
| Publish to the App Store / Google Play | The store accounts are the owner's |
| Issue API tokens for the project | A token drives the project as you — it's a key to everything |
| Buy, verify and attach a domain | Domains belong to your Estage account, not to one project |
| Buy a Dedicated Cloud or a plan | It's the owner's subscription and the owner's bill |

Inviting and role changes are the one exception you can override: if you edit a role and tick
**Members & Roles → Invite / Change roles**, that role really can manage access. It's off in every
built-in role, so nothing changes unless you deliberately turn it on.

## It tells people what they can't do — before the click

Controls a role can't use are **visibly disabled, with the reason on them**, instead of failing
after the click. If something is refused anyway, the message names the **permission that's
missing** rather than showing a generic error.

## Assigning a role

**When inviting** — pick the role in the invite form before sending. See
[Members](/project-settings/members/) for how invitations work.

**Later** — open **Members**, find the person, and change their role. It takes effect immediately.

A person can also get access through a shared folder, and folder shares carry a role too. If
someone has access from both a folder and the project directly, they get the **sum** of the two —
whichever gives more, wins.

## Creating your own role

**Project Settings → Roles → New role.**

You'll get the full list of capabilities as a checkbox tree, grouped by area:

| Area | Covers |
| --- | --- |
| **Project** | Adding and removing apps (Website / Web app / Mobile app) |
| **Building** | AI chat, visual editor, pages, images, revert |
| **Publishing** | Website, web app |
| **Project Settings** | Every settings tab, with view and edit as separate ticks |
| **Dedicated Cloud** | The project's own database, auth and email |
| **Server** | The web-app box — scale, restart, install, shell |
| **Blog** | Posts, categories, authors |
| **Marketing Funnels** | The graph, its pages, stats, leads |
| **Audiences** | Visitor segments and copy variants |
| **Members & Roles** | Who can get in, and with what authority |

A few checkboxes are marked **sensitive** — Code Injection, Payment Processing, Connectors, adding
and removing apps, and the three access controls (invite, change roles, remove access). They're the
ones where a mistaken tick is expensive: arbitrary JavaScript on your live site, where the money
goes, your third-party API keys, and access itself.

Custom roles belong to one project. Editing a role changes what everyone holding it can do,
straight away.

## Things worth knowing

- **Everyone spends their own AI credits.** A collaborator running AI builds draws on their own
  balance, not yours. You can top them up from the Members tab — see
  [Gifting credits](/project-settings/members/#gifting-credits).
- **Purchases and consumption that bill the project go to the owner.** The
  [Dedicated Cloud](/cloud/), the [web app](/platform/web-apps/) server, and the site's
  [AI Assistant](/ai-assistant/) are billed to the project, which means to whoever owns it — no
  matter which member triggered the spend.
- **Existing collaborators keep the access they had.** Anyone added before roles existed shows up
  as an **Admin**, which is exactly what they could already do. Narrowing someone is always your
  decision, never something an update does to you.
- **Community roles are set inside the community.** Moderation, channels and courses have their own
  permissions in the community product. The Community tab in project settings only controls the
  binding between the two.