Managing multiple SGEN sites

What is this for?

The multi-site management surface gives Platform Admins a single view across every site in their organization's portfolio. From the org-level dashboard, you can monitor health and activity across all sites, manage users at the org level, enforce consistent security policies, and review cross-site billing — without switching between individual site admin panels.

The key principle: things that should be consistent across all sites (user identities, security policies, brand assets) live at the org level. Things that are site-specific (content, Custom Codes, page structure) live at the site level. Mixing the two is what creates management overhead at scale.

At 2 sites, this discipline feels like ceremony — ad-hoc coordination handles everything in minutes. At 8 sites the ad-hoc model breaks: adding a new hire to every site takes an hour, and missing one is a real risk. At 12 sites it produces wrong outcomes — inconsistent access, drifted brand assets, security policies that disagree across sites — and nobody notices, because no one person looks at all 12. Org-level discipline is the only model that scales linearly with portfolio size.

A sample four-site portfolio as it appears in the org dashboard's site list.

Good use cases

What NOT to use this for

How this connects to other features

Before you start

Where to find it

Open SG-Admin. If your account has org-level Platform Admin access, the top navigation shows an Organization item alongside the site-level items.

The org-level dashboard is the home tab under Organization. It shows every site in the portfolio with health, uptime, last-activity, and last-backup timestamp per site; a roll-up of recent Activity Log events across all sites; pending billing items and upcoming renewals; and a cross-site user roster showing authentication status per user across all sites. Bookmark it — it is the morning sweep destination for anyone managing more than two sites.

The site list at the top is the busiest part of the screen. Each row gives you four things at a glance: the site's display name, its plan tier, when it last successfully backed up, and the timestamp of the most recent admin or content activity. Status pills on the right call out anything that needs attention — a stale backup, an offline site, a site that has not seen activity in an unusual amount of time. The column ordering is fixed so the eye learns where to look; you do not need to re-sort the list to find the same data twice.

The Organization overview panel below the site list is the second thing to read. It summarizes the portfolio totals and surfaces any alerts that span multiple sites. A site-level alert appears in the site row above; an org-level alert (a policy that needs review, a renewal that is approaching, a user who hasn't completed onboarding) appears in the overview panel.

Setting up consistent naming across sites

Before adding your third site, document your naming convention. A workable pattern:

The pattern matters more than which one you pick. Apply it to the site's display name in the org dashboard as well as the domain or subdomain, so the naming is consistent everywhere the site appears.

A short shared document captures the convention for everyone who creates sites. Keep it under one page so it is read:

# Your Store — site naming convention (v1, owned by Platform Admin team)
## Display names (shown in the org dashboard)
# Primary production: Your Store
# Other production: Your Store — Wholesale
# Your Store — Events
# Staging: Your Store — Staging
# Internal-only: Your Store — Internal
## Domains and subdomains
# Primary custom domain: yoursite.com
# Other custom domains: wholesale.yoursite.com
# events.yoursite.com
# Staging (SGEN sub): yourstore-staging.sgen.com
# Internal (SGEN sub): yourstore-internal.sgen.com
## Rules
# 1. Display name + domain must be decided together; do not change either alone.
# 2. Staging sites are tagged Staging in the org dashboard. Never run live traffic on them.
# 3. New sites added by anyone other than a Platform Admin must be reviewed within 7 days.
# 4. Site naming changes require sign-off from a second Platform Admin.
# 5. When a site is retired, archive its display name. Do not re-use it for a different site.

The one-page naming convention shared with every Platform Admin — reviewed at portfolio onboarding.

Managing users at the org level

Role assignment by site: the same person can have different roles on different sites. A content manager may be a Platform Admin on the primary marketing site but only an Editor on the event site. Assign roles at the site level; the identity is managed at the org level.

The split between identity and role is the central pattern. The identity — the email address, the password, the 2FA enrolment, the SSO connection — is created once at the org level and travels with the person across every site they touch. The role — Platform Admin, Editor, Author, Contributor — is set per site and reflects what the person does on that site. This is why org-level deactivation revokes access everywhere in one action: the identity is gone, so the per-site roles attached to that identity stop authenticating.

Avoid the temptation to create a duplicate account for someone on a second site rather than promoting the existing org-level identity. Two accounts for the same person means two sets of credentials, two 2FA enrolments to maintain, two audit trails to reconcile, and two deactivations to remember on offboarding. The org-level identity costs nothing extra; use it.

Setting org-wide security policies

For SSO configuration, see the two-factor authentication and SSO guide — SSO is also configured at the org level and applies to all sites.

The reason these settings are org-wide and not per-site is operational, not technical. If two sites in the same org run different security policies, the weaker site becomes the entry point for an attacker who already has an org-level identity — the 2FA enforcement on the stricter site is bypassed by signing in through the weaker site first, then pivoting across the shared identity. The unified policy closes that gap. If your business genuinely needs different policies for different sites, that is the strongest possible signal that those sites belong in separate orgs.

When you change an org-level policy, the change applies to all sites at the next user session. There is no per-site rollout, no canary group, no schedule. Communicate the change to all site teams before saving — particularly if you are tightening a policy (raising the minimum password length, enabling 2FA enforcement) that will force users to take action on their next login. A 14-day grace period for 2FA enforcement gives users time to enrol without a hard lockout on the morning of the change.

Cross-site reporting

Some metrics matter at the org level, not per site.

The security event roll-up deserves the most attention of the four. A spike in failed login attempts on one site is a per-site investigation. A spike in failed login attempts across three sites at once is a different signal — it suggests an attacker is rotating across the portfolio. The org-level view is the only place where that pattern is visible at all. Set a recurring time once a week to glance at the roll-up; the cost is two minutes and the upside is catching a coordinated attempt before it converts.

These aggregates are available in the org dashboard. Per-site analytics — post-level views, traffic source breakdown, conversion events — remain in each site's SG-Dashboard. For compliance reporting or budget reviews that require the full cross-site picture, the org dashboard's export function produces a summary covering all sites in the portfolio; the per-site Activity Log exports cover site-level audit evidence.

The aggregate page-view trend over the last six months is the quickest read on whether portfolio traffic is steady, growing, or shrinking. Use it to spot a site that is dragging the portfolio down, or a site that is quietly carrying the bulk of audience demand.

Monitoring backup health across the portfolio

From the org dashboard:

The reason backup health is the first thing the morning sweep looks at is that a backup miss compounds in a way that other portfolio issues do not. A drifted brand asset is fixed in a few minutes. An outdated user role is fixed in seconds. A missed backup, however, means that if anything goes wrong with the site before the next backup succeeds, the recovery point jumps from "yesterday" to "last week" or worse. Most customer-facing damage from a site incident is not the incident itself — it is the data lost between the last good backup and the moment of recovery. Backup stale is the only org-dashboard alert that should interrupt other work the moment it appears.

A site with status Backup stale in the org dashboard means the last successful backup is older than expected for that plan tier. This could be a failed backup run, a plan change that altered the schedule, or a new site that hasn't yet completed its first backup. Investigate each case.

In this snapshot, the Backup stale count of 1 is the actionable item — that is the events site flagged in the earlier list view. Everything else is green. The morning sweep is done after the stale-backup site is investigated and resolved.

Maintaining a shared brand asset library

For sites that share a brand identity — a franchise, a parent-and-sub-brand structure, a multi-region portfolio — maintain one canonical source for brand assets. Fragmented brand management is the number one source of visual inconsistency across a portfolio.

When the brand updates — a logo refresh, a new color palette, a typography change — update the canonical source first, then apply to each site in the portfolio. Document the update in the team ops notes so all site teams know what changed.

The reason brand drift is the hardest problem to fix later, not earlier, is that no single update breaks anything visibly. A button on one site uses last year's accent color while another site uses this year's. A logo on a footer was never replaced when the new variant shipped. A heading typeface was set to the old weight on one site because the new weight had not been uploaded yet. None of these are urgent on the day they happen. Six months later, when a stakeholder pulls up the sites side by side, the brand looks tired — and the work to align everything is real, because each site needs its own visit, its own asset update, and its own verification pass. The monthly spot-check catches drift while it is still cheap to fix.

For organizations large enough to have a separate brand team, the brand team should own the canonical asset folder and the team operating SGEN should pull from it. For smaller organizations where the Platform Admin team also owns the brand assets, designate one Platform Admin as the brand-asset owner so updates have an accountable single source. Either way: one canonical source, all sites pull from it, drift is caught monthly. Anything else compounds into a brand-refresh project that nobody scheduled.

Running a monthly org-level sweep

The monthly sweep is the operating discipline that keeps a portfolio healthy without anyone having to react to a stakeholder report. Schedule it for the same day each month — the first Monday is common — so it survives team changes and competes successfully for calendar space with the inevitable urgent items.

The order matters. Backups first because backup failures are the only items that compound in cost the longer they go unaddressed. User roster second because inactive accounts are a security surface that grows over time and a tidy roster makes other reviews faster. Activity log roll-up third because it surfaces the unexpected — the items you would not have known to ask about. Backup verification, billing, and brand checks last because they are smaller in stakes and benefit from the cleared attention left after the first three checks are complete.

The sweep takes 15-30 minutes depending on portfolio size. Add it to a shared calendar item so it survives team changes — the sweep should happen whether or not the usual admin is available.

Example scenarios

Four realistic situations showing the patterns from this guide in practice.

Portfolio architecture at a glance

The shape of a healthy single-org portfolio is straightforward: one organization holds every site the business runs, security and identity flow from the org level down to each site, and each site keeps its own content and configuration. A sample four-site portfolio, with the security and identity boundary drawn at the org level:

Reading the shape: the organization sits at the top. The sites below it are the four boxes. The inheritance lines are not data flow — they are the policy and identity inheritance lines. Every site inherits the same org-level security policy. Every user managed at the org level can be assigned a role at any of the four sites. Content, Custom Codes, and per-site analytics live inside each site and do not flow between them.

A portfolio that does not look like this — for example, four sites where each one has its own users list and its own security policy — is a portfolio that has not been set up org-first. The recovery is real work: consolidating users, aligning security policies, and re-onboarding the team to the org-level surfaces. Avoid that recovery by getting the org-level setup right before adding site #3.

When to split into multiple SGEN orgs

Most portfolios fit under one org. You would split into separate orgs only if:

If none of these apply, stay in one org. The unified view, unified security policies, unified user management, and unified billing overview are all stronger in one org than split across two.

If you are considering a split, talk to your account representative first. Migration between orgs is non-trivial — it involves data transfer and a period where access management must be handled manually. The decision is meaningfully easier to make before a site has live traffic and a content history.

A useful test before committing to a split: imagine writing one shared security policy that applies to every site in question, with no per-site exceptions. If you can describe one policy the team would agree to, the sites belong in one org. If two sites genuinely need different policies that cannot be reconciled — different password rules, different 2FA enforcement, different session timeouts — that is a clear org-split signal. Run the same test for users: imagine one user list that spans all sites with per-site role assignments. If that user list is readable and accurate, one org is correct. If it is unreadable because the same email represents different real people on different sites, the sites belong in different orgs.

Most teams who think they need an org split discover, on running these two tests, that one org fits. The desire for separation is often a desire for cleaner per-site reporting or scoped access for a specific team — both of which are solvable inside one org through site-level role assignments and the per-site analytics surfaces. Reserve the org split for the cases where the legal, regulatory, or confidentiality boundary genuinely requires it.

What success looks like

A well-run multi-site portfolio has four signals.

If all four are green, the portfolio is under control. If any one is amber — a stale backup, an inactive account, a site with different security settings, a brand mismatch — address it in the next monthly sweep rather than letting it accumulate. The monthly sweep's value compounds: a portfolio swept 12 times a year never drifts far enough to require a major correction session.

A useful framing: the difference between a portfolio that needs constant attention and one that runs cleanly is not the number of sites, the size of the team, or the complexity of the content. It is the discipline of putting org-level work at the org level and per-site work at the site level. Teams that hold that line operate 8-site portfolios with the same effort other teams spend on 3-site portfolios. Teams that do not hold the line spend an outsized portion of their week on coordination overhead that should not exist.

The four signals above are the read on whether the discipline is holding. If you can show a stakeholder the org dashboard and the four signals are green, the portfolio is in a defensible state. If any one is amber and has been amber for more than a sweep cycle, the discipline has slipped and the recovery work is the next priority.

Anti-patterns

The shared pattern across these anti-patterns is treating per-site operations as the default. The org-level surfaces exist precisely so the team does not have to repeat work for every site. When you find yourself opening a site's Users list to add someone who already has an org-level identity, or copying a Custom Code from one site to another, or setting different security policies for two sites in the same org — pause and ask whether the work should happen at the org level instead. The right answer is usually yes, and the time spent doing it correctly compounds across every subsequent operation.

The discipline takes a few weeks to become automatic. The portfolio that runs cleanly six months in is the one where the team built the org-first habit early. The portfolio that needs a major cleanup project is the one where the per-site shortcuts were taken too often in the first six months.

Troubleshooting

Common issues and their fixes.

Planning for growth

If your portfolio is likely to grow from 3-4 sites to 10+ over the next 12-18 months, set the structural patterns now rather than retrofitting them later.

The portfolios that scale gracefully are the ones where the structural decisions were made early and revisited periodically. The portfolios that need expensive remediation are the ones where every site was added under operational pressure, each in its own configuration, with cleanup deferred to a later date that never arrives. The earlier the discipline lands, the cheaper it stays.

Related reading

What to do next