Multi-site permissions and roles in SGEN
How to scope team access across the sites in your account
Permissions in SGEN work at two levels: the account level (which sites a person can see at all) and the per-site level (what they can do inside each site). Most teams set up at the account level and never touch the per-site layer. Agencies and operators running mixed-sensitivity portfolios usually need both.
This guide explains how the two layers fit together, when to use which, and what the practical patterns look like for the common multi-site scenarios — brand portfolio, agency operations, regional split, and acquisition rollup.
What is this for?
Multi-site permissions decide three things for each teammate:
- Which sites under your account they can see and access at all.
- What role they hold on each site they have access to. Different sites can give the same person different roles.
- Whether new sites added later auto-include them or not.
The platform's roles are scoped per site. A teammate who is admin on site A can be editor on site B, viewer on site C, and not present on site D — all under the same account.
Three role layers exist:
- Account-level roles. Apply at the account level: who can add new sites, change billing, see the cross-site dashboard, and act as account owner.
- Inherited per-site roles. When you provision a new site with Inherit team access checked, the account team is copied to the new site as the starting roster. Each member's role on the new site mirrors their account-level role unless you override.
- Per-site overrides. Manual changes to a specific site's team that diverge from the inherited pattern. Adding someone not in the account roster, removing someone the inheritance brought in, or changing a role from admin to editor for one specific site.
The combination gives you fine control without forcing per-site setup on every site.
Good use cases
All eight content writers should see all client sites. All four designers should see all client sites. The CEO should see all sites and billing. The agency operations manager should see all sites but not billing. Pattern: set everyone at the account level with appropriate account roles; let inheritance carry them onto every new client site.
A three-person operations team manages Acme Coffee, Acme Wine, and Acme Bookstore. All three teammates should see all three sites. Pattern: add the three people at the account level once; they appear on every site automatically.
Acme Coffee US team should see only the US site. Acme Coffee UK team should see only the UK site. The brand director should see both. Pattern: add the brand director at the account level; add region teams as per-site members only on their own site without account-level seats.
Most clients are normal — the full agency team works on them. One client has confidential pricing data and only two agency staff are cleared to work on it. Pattern: leave inheritance off for the sensitive client site; explicitly add only the cleared two.
When you acquired a brand, their existing team had been managing their site for years. After rollup, you keep the original team scoped only to the acquired brand's site, plus add your account-level admin team to oversee. Pattern: acquired team as per-site only; your team inherited.
A temporary contractor needs access only to one campaign site, only for the campaign duration. Pattern: per-site add for the contractor on the campaign site only; remove after campaign closes.
The finance team needs billing access at the account level but should not be able to edit any site's content. Pattern: account-level role of viewer plus billing-access toggle on for finance staff.
A senior stakeholder wants to see all sites in view-only mode without being asked to edit anything. Pattern: account-level viewer; inheritance carries view-only access onto every site.
What NOT to use this for
Permissions in this guide are for your admin team — the people who log in at /sg-admin/. End-user accounts (visitors who sign up on your public site) are a separate system documented under customer accounts.
Permissions are at the site level, not the page level. A team member who has access to a site can see all pages on it. Per-page hiding is not part of the role model.
Each teammate gets their own account. Shared logins break the audit log and the per-user activity record. Add separate accounts for each person.
A role on one account does not transfer to another account. Each account has its own team roster.
The roles in this guide do not control what visitors see on the live site. Public access is controlled separately via the visibility settings on each page.
Inheritance is a starting roster, not a renewable lease. For time-bounded contractor access, use a per-site override with manual cleanup at the end.
API keys are managed separately — they are not bound to a team member's identity. Adding a teammate does not give them API keys; they create or are granted keys explicitly per site.
How this connects to other features
The account-level roster is at Account → Team. This is where you add or remove people at the account level.
Inside any site, Site → Settings → Team shows that site's roster and allows per-site overrides.
The Inherit team access checkbox at provisioning time decides whether the account roster copies onto the new site.
Visibility on the cross-site analytics view follows account-level role, not per-site role. Someone with account-admin can see analytics for every site under the account.
Billing access is an account-level setting. Per-site role overrides do not affect billing visibility.
Per-site actions log who did what on each site. The audit log respects role visibility — viewers see less detail than admins.
API keys are scoped per site. Granting a team member admin on a site lets them create or revoke that site's keys.
Account-level SSO (if available on your plan) applies across all sites. Sign-in policies (password requirements, session length) are account-level too.
Before you start
A short checklist before changing team access:
Pattern-pick guidance:
- Map your team's intent. Who should see what sites, and at what role? Sketch it on paper before you start clicking — it is much faster than guessing in the admin.
- Identify the account owner. One person has the account-owner role and can grant or revoke account-level admin. Confirm who this is before granting elevated access.
- Pick a baseline pattern. For most teams, "everyone at account level, inherit on new sites" is the right baseline. Override only where you have a clear reason.
- Plan for departures. A teammate leaving the team is a per-account removal action. Plan how you will know to do it (HR signal, calendar reminder, exit checklist).
- Document the model. A simple text file in your team's shared notes that lists your permission pattern saves arguments months later. Re-read it before adding a new teammate.
Where to go
The two main locations:
- Account team. Account → Team. Lists everyone with account-level access, their role, and the sites they touch. This is where you add account-level people.
- Per-site team. Inside each site, Site → Settings → Team. Lists that site's roster — the account-level inheritance plus any per-site additions.
A third less-used location:
- Audit log. Account → Audit Log. Records every permission change. Useful when something looks off and you want to know who changed what when.
The Team page shows each member with their role pill and the sites they have access to. Hovering on a site name shows whether their access there came from inheritance or per-site override.
Steps — Set up multi-site permissions
1. Add a teammate at the account level
Open Account → Team → + Add Member. Enter the teammate's email, pick an account-level role, and decide whether they have billing access.
Account-level roles cascade to every site under the account by default. An account admin is admin on every site; an account editor is editor on every site; an account viewer is viewer on every site.
If the teammate is not in your account yet, they receive an invitation email. Once they accept, they appear in the team list.
2. Choose between Inherit on new sites or not
The teammate's account-level role decides whether they appear on new sites you provision later.
- If their account role is anything other than Per-site only, they auto-appear on new sites when you check Inherit team access during provisioning.
- If their account role is Per-site only, they do not auto-appear. You add them per site manually.
This is how you keep an agency's operations team on every client site while keeping a client-side contributor scoped to one client site.
3. Add a teammate per site (without account access)
Open the target site's admin. Navigate to Site → Settings → Team → + Add Member.
Enter the teammate's email and pick a per-site role. They appear on this site only. They cannot see other sites under your account.
This is the right path for client-side staff in an agency context, regional content leads, or temporary contractors.
4. Override an inherited role on a specific site
If a teammate inherited account-admin onto a site but you want them as editor on just that site, open Site → Settings → Team → [member] → Change role.
The change applies to that site only. Other sites the member has access to keep the original role.
Per-site overrides do not propagate. Changing site A's role for the member does not change site B.
5. Remove a teammate from one site only
If a teammate inherited access onto a site you want them off of, open Site → Settings → Team → [member] → Remove from site.
The member loses access to that site. They retain access to other sites their inheritance or per-site adds gave them.
Removing from one site is not the same as removing from the account. Use Account → Team → [member] → Remove from account if you want them off the account entirely.
6. Promote a per-site member to account-level
If a per-site member should become an account-level admin, open Account → Team → [member] → Edit → Account role. Change from Per-site only to Account admin (or whatever role fits).
They now have access to every site under the account based on inheritance settings. Existing per-site role overrides stay in place — the account-level role does not erase per-site exceptions.
7. Audit the team periodically
Quarterly or semi-annually, open Account → Team and review:
- Are all listed members still part of your organization?
- Do their roles match what they need today?
- Are there per-site overrides that no longer serve a purpose?
The audit catches stale access from departed contractors, role drift over time, and per-site exceptions that nobody remembers setting up.
For agencies, the audit also catches client-side staff who left the client's team but are still active on the client's SGEN site.
8. Document the pattern
After setting up, write the pattern down. Your future self and future teammates need to know:
- Who is an account-level admin and who is per-site only.
- What inheritance posture you use (default-include vs default-exclude on new sites).
- Which clients (agency) or sites (operator) have non-standard scoping and why.
A two-paragraph note in your team's shared docs serves better than a complex policy document. Update it when the pattern changes.
9. Handle a teammate leaving
When a teammate leaves your organization:
- Remove them at the account level via Account → Team → [member] → Remove from account. This revokes account-level access and removes them from inheritance lists.
- Their per-site overrides on individual sites also need explicit removal — the platform asks you in a confirmation step whether to clear per-site memberships.
- Confirm by reloading each site's Team page that they no longer appear.
For thoroughness, run an audit log query for actions taken by the departed teammate in the last 30 days. This is more about confirming the handover than about distrust.
What success looks like
A working multi-site permission setup feels like: For a brand-portfolio operator: the team's daily experience is "log in, see all our sites, work on whichever needs attention." Permission setup is invisible because it just works. For an agency: client-side staff log in and see their own site. Agency staff log in and see all clients. No client accidentally sees another client's data. For a multi-region operator: each region's content team operates in isolation. The brand director gets the cross-region picture without each region's team needing access to the other.
- Every teammate sees only what they need to see when they sign in. The Sites list on SG-Dashboard shows them their relevant sites and nothing else.
- New sites you provision automatically include the right people without you adding everyone manually.
- Per-site exceptions are rare and intentional. When you look at a site's team page, you can name the reason for any non-standard membership.
- Audit log queries against "who changed X" return clear actor names, not shared accounts.
- Departures are handled in one action at the account level. No teammate retains access by accident after leaving.
- The cross-site analytics view aggregates only the sites the viewer should see.
What to do if it does not work
Less-obvious cases:
Check both layers. Account → Team → [member] shows their account role and site list. Site → Settings → Team on the missing site shows the per-site roster. The teammate may need to sign out and back in if access was granted recently.
Check inheritance. They may be an account-level member whose role inheritance carried them onto the new site. Either remove from that site (per-site override) or change their account role to Per-site only.
Per-site overrides set the role explicitly. Open Site → Settings → Team → [member] and change the role.
They may have signed up with a different email than the one you invited. Check the email address spelling. Re-invite with the exact email they use.
It only appears once your account has more than one team member. If you are the only person on the account, the checkbox is hidden because there is no team to inherit.
Billing access is a separate toggle, not bundled into the role. Open Account → Team → [member] → Edit and check the Billing access checkbox explicitly.
Their session may be cached. Have them confirm sign-out; the platform invalidates their session on next request.
Reload the page. The Team page caches briefly; a reload pulls the latest from the server.
Click the actor name to see what other actions they took. Most often this is a teammate who handled a permissions update on your behalf.
Worked example — Acme agency onboards client #9
Acme Studio runs SGEN sites for eight clients and is onboarding a ninth — a regional bookstore chain. The agency's pattern, after two years of iteration:
- Provision the new client site. The agency operations manager creates
Bookstore Chain — Sitefrom SG-Dashboard, picks Starter tier (will upgrade later as traffic grows), uses the agency's "client starter" site as the clone source, and checks Inherit team access. - Inheritance brings on the agency team. Three agency content writers, four designers, the operations manager, and the brand director all auto-appear on the new site with their account-level roles (editor for writers, admin for the senior staff).
- Add the client-side staff per-site. The bookstore chain has two staff who will manage their own site day-to-day. The operations manager adds them via Site → Settings → Team → + Add Member as per-site editors on the bookstore site only.
- Override one agency role for sensitive content. One section of the bookstore site will contain author-contract drafts that should stay agency-staff-only. The operations manager removes the four designers from this site (per-site removal) — they were inherited but do not need access. They remain on the eight other client sites.
- Document the exceptions. The operations manager updates the agency's shared notes: "Bookstore Chain — designers excluded due to confidential drafts. Re-include if the confidentiality requirement lifts."
- Quarterly audit. Three months in, the agency does its routine audit. The bookstore staff are still active. One of the writers left the agency two months ago and was removed at the account level then; the audit confirms no per-site override left them lingering anywhere.
The pattern lets the agency move fast (one click on new sites includes most of the team) while still letting them tighten access where it matters.
Worked example — Acme brand portfolio shares one team
Acme Coffee Roasters runs three sites (Coffee, Wine, Bookstore) with a three-person operations team. The setup:
- All three operations staff were added as account-level admins. Each got a Site access toggle on for all three sites.
- Inheritance set to default-include. When the team adds a fourth brand site next year, the same three people auto-appear.
- No per-site overrides. Every site has the same team. The simplicity makes everything easier — onboarding new sites takes one minute, offboarding a teammate takes one action.
- One exception added later. A part-time contractor was hired for three months to help with seasonal campaigns. They were added per-site to all three sites as an editor (not admin) with a calendar reminder to remove after the three-month engagement.
- Quarterly audit. Confirms the contractor was removed on schedule, the three staff still have current access, and no surprise per-site additions exist.
This pattern is the simplest workable setup and serves most brand portfolios well. Only complexity-add when you have a clear reason.
Notes on inheritance, defaults, and audit
A few details worth memorizing because they reshape day-to-day work:
Inheritance is one-way at create time. When you provision a new site with Inherit team access checked, the account team copies once. If you add a new account-level admin a month later, they do not auto-appear on existing sites. You either run a fresh inheritance pass or add them per-site to existing sites.
Account role determines default per-site role. The mapping is:
- Account admin → admin on every site
- Account editor → editor on every site
- Account viewer → viewer on every site
- Per-site only → no default; needs explicit per-site add
Per-site overrides are sticky. Once you override a member's role on a specific site, future changes to their account-level role do not re-set that site's role. The override stays until you explicitly clear it.
Billing access is account-only. No per-site billing role exists. A teammate either has billing access or they do not.
Audit log records every change. Every team-member add, remove, role change, and inheritance pass shows in Account → Audit Log with actor, timestamp, and before/after values.
Account owner cannot be demoted by themselves. Only another account owner can demote the current owner. The platform enforces one account owner at minimum.
Removing a teammate from the account also removes them from every site. This is the safest path for offboarding. Per-site cleanup is implicit.
Common questions
What happens if I remove someone at the account level but they still have per-site overrides? The account removal asks you to confirm whether to also clear per-site memberships. Confirm yes for full offboarding.
Can I temporarily disable a teammate's access without deleting their account? Yes — change their account role to a more restricted role, or remove them per site. To pause without removing, the simplest action is per-site removal with notes on when to re-add.
Can a teammate hold different roles on different sites? Yes. That is exactly what per-site overrides are for.
Do per-site roles affect the cross-site analytics view? The cross-site analytics aggregates the sites the viewer has access to. Per-site role determines what data they see for each site (admin sees full analytics; viewer sees limited).
Can I prevent a teammate from changing the Theme Editor on one site? Yes — set them as editor or viewer on that site (admins can change Theme Editor; editors and viewers cannot, depending on the platform's role matrix).
Is there a "support access" role for external help? Some plans include the option to grant temporary support access. Check Account → Settings → Support Access if your plan offers it. The role grants short-term scoped access for the SGEN support team to your account.
Can two teammates have account-owner role? The platform enforces one account owner. To transfer ownership, the current owner promotes another teammate via Account → Team → [member] → Transfer ownership.
What is the difference between editor and viewer on a site? Editor can create, edit, and publish content. Viewer can only see content and reports. Specific capability mapping is on the role-reference page.
Can I export the permission setup as a CSV? The Team page supports CSV export. Use Account → Team → Export → CSV for a snapshot you can audit offline.
Will adding a per-site member generate a notification? The added member gets an invitation email if they are not already on the account, or a notification email if they are already an account member.
Can I bulk-update roles across multiple sites? Not in one action. Bulk updates go through the account-level role (which propagates via inheritance) or are done per site one at a time.
What if a teammate logs in but their site list looks empty? Their access may have been removed or they may have signed in with the wrong email. Confirm both before troubleshooting further.
Does account-level SSO replace per-team-member sign-in? If account SSO is enabled, team members sign in via SSO. Their roles still come from the account team list, not from SSO group membership (unless your plan supports SSO group mapping, which is a separate setting).
Related reading
Multi-site permissions reward careful upfront thinking. Spend 15 minutes mapping your pattern before you start clicking, and you will save hours of cleanup later. The next read is consolidated reporting across sites, which depends on permissions being set up correctly.
Add a second site to your account — the provisioning entry point.
Cross-site template sharing — reuse design and templates across sites.
Consolidated reporting across sites — portfolio-wide reporting.
Agency client portfolio setup — agency-specific permission patterns.