Roles & Permissions
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
Section titled “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
Section titled “What each one covers”Contributor
- 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
Marketer
- 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
Admin
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.
What only the owner can do
Section titled “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
Section titled “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
Section titled “Assigning a role”When inviting — pick the role in the invite form before sending. See 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
Section titled “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
Section titled “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.
- Purchases and consumption that bill the project go to the owner. The Dedicated Cloud, the web app server, and the site’s 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.