# Roles & Permissions

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

Source: https://support.estage.com/project-settings-roles
Part of the ESTAGE Support help center (https://support.estage.com). Full knowledge base: https://support.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, Pixels & Tracking, Analytics, Email Integrations, 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, Overview, SEO, Pixels & Tracking, Analytics,
  Languages, Global Variables, AI Assistant, Recaptcha
- **Settings, view only** — Payment Processing, Connectors, Code Injection, Security, Email Integrations
- **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, Pixels & Tracking, Analytics, Email Integrations
- **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, or build a desktop installer | The store accounts and the signing certificate 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, attach and delete a domain | Domains belong to your ESTAGE account, not to one project. Its DNS records and country filters are delegatable — see [Domain](https://support.estage.com/domains-dns-and-traffic) |
| 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. A few panels go further and simply don't draw the controls — the DNS records of
a domain you can only view show no Add form and no per-row buttons, because a disabled form is
still something you have to click to understand. Either way the page says why, once. 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](https://support.estage.com/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 / Desktop 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 |
| **CRM** | Dashboard, Contacts, Lists, Suppressions, Tags |
| **Engage** | Messages, Broadcasts, Automations — *Send* is its own tick, because a broadcast can't be recalled |
| **Commerce** | Orders, Products, Coupons |
| **[Bookings](https://support.estage.com/crm-bookings)** | My bookings, Meeting types and Availability, on one tick — see who booked and what's bookable |
| **Affiliates** | The affiliate program |
| **Members & Roles** | Who can get in, and with what authority |

A few checkboxes are marked **sensitive** — Code Injection, Payment Processing, Connectors,
[Domain](https://support.estage.com/domains-dns-and-traffic), adding and removing apps, the three access controls (invite,
change roles, remove access), and the destructive ticks in the CRM areas (deleting contacts,
cancelling a booking). 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, a DNS zone that carries your
email too, access itself — and mail that reaches people the moment it's sent.

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](https://support.estage.com/project-settings-members#gifting-credits).
- **Purchases and consumption that bill the project go to the owner.** The
  [Dedicated Cloud](https://support.estage.com/cloud), the [web app](https://support.estage.com/platform-web-apps) server, and the site's
  [AI Assistant](https://support.estage.com/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.