For Platform Admin: Getting Started in SGEN

How to hit the ground running as a Platform Admin

The Platform Admin role is the operator at the top of the organization tree. You run two or more SGEN sites for the same company — a marketing site, a documentation site, a careers site, a regional landing-page set — and the policies that apply to one site apply to all of them.

Your scope is org-level, not page-level. You provision sites, you grant access, you watch the billing, you set the security posture, and you delegate the page-by-page work to the named roles that own each surface. The role rewards a steady cadence over heroics: audit before reacting, monitor before debugging, document what changed.

This guide walks you through what your access includes, the day-one setup that gives you a clean baseline, the daily, weekly, and monthly cadence that keeps the portfolio healthy, and the escalation paths that keep you from sitting on a problem that needs help.

30-second pitch for the role

You hold the keys to the organization. You decide who gets in. You decide what site exists. You decide what plan tier each site runs on. You decide whether the security policy is two-factor on or off — and "off" is not the right answer. The role rewards consistency: setting one policy across every site, applying it uniformly, and writing it down so a future Platform Admin inherits a clean baseline.

What is this for?

The Platform Admin role is for the team member who runs the SGEN organization layer — the surface above any individual site. Typical scenarios: a company runs five sites and needs a single dashboard, a media group runs twenty subsites with shared branding, a multi-location franchise needs each location to operate as its own site under a shared org, or a single business has grown from one site to "main site plus three campaigns plus a docs site."

You are not the Content Editor. You are not the Marketing Manager. You set the boundary inside which those roles work. Most days you are not opening individual blog posts — you are reading the org dashboard, granting access to a new hire, reviewing the billing console, and verifying backups.

Good use cases

• A new team lead joins the marketing department and needs admin access to two of the five sites — open the org dashboard, add the user, assign roles per site.
• The CFO asks why the SGEN bill went up — open the billing console, find the plan upgrade event, document the trigger, send the answer back the same day.
• A new product line gets its own marketing site — provision the new site, apply the org's default plan tier, hand admin to the team lead, add the site to the weekly health rotation.
• An employee leaves the company — disable their login immediately, reassign any content they own, and remove them after the 30-day window.
• The annual security audit asks for a list of every admin-tier user across the portfolio — pull the org-level user report, mark anyone with elevated access who has not logged in for 60+ days, schedule downgrade conversations.

What NOT to use this for

• Editing blog posts or pages. Content belongs to the Content Editor role. You can technically reach the editor, but doing the work yourself blurs the boundary and creates an audit trail that confuses the next month's review.
• Running campaigns. Forms, popups, lead routing, email sequences — those belong to the Marketing Manager. You set who can do that work; you do not do it.
• Granting Platform Admin role on first request. Elevation to your own tier requires written approval from a peer Platform Admin. Refer all such requests to your governance process.
• Skipping the disable-then-delete pattern. Removing a user is two actions, not one. Disable first, wait the recovery window, then delete. Anyone who insists on immediate deletion is asking you to skip the audit trail.
• Approving a plan downgrade without checking usage. Every plan tier has quotas. A downgrade can push a site over its new quotas the moment it lands.
• Setting security policies site-by-site. Two-factor, login throttling, and password rules apply org-wide. Setting them per-site creates inconsistency that attackers exploit.

How this connects to other features

• For Content Editor — the role you most often grant to a new hire. Know the surface they will live in so you set the right scope.
• For Developer — the role that touches Custom CSS, Custom Codes, and redirects. Grant carefully — these surfaces carry the most platform risk.
• For Partner / Agency — if an outside agency builds for you, you grant them Partner-tier access on a per-site basis. Audit quarterly.
• SGEN Glossary — confirm the platform's language before writing internal SOPs that name SGEN surfaces.
• FAQ — the customer-facing short answers. Familiarize yourself so internal questions that match the FAQ get the same canonical answer.

Before you start

• The organization has been set up on SGEN and you are listed as Platform Admin.
• Two-factor authentication is enabled on your own account (no exceptions).
• You have a recovery contact configured on your account.
• You have access to the org's billing email address and the payment method on file.
• You have read the org's internal documentation policy (or you are the one writing it).
• You have a one-page list of every site in the portfolio, with the team lead and plan tier per site.

If two-factor is not on for your own account, fix that before you do anything else. The Platform Admin role is the most consequential surface in the organization. A compromised Platform Admin account is the worst-case incident the rest of this guide is trying to prevent.

Where to go

The surfaces a Platform Admin touches across the portfolio:

You will use the org dashboard most mornings. You will use the billing console on the first of each month. You will use the audit log when something does not match the story someone is telling you.

Steps

1. Sweep the org dashboard every morning

Open the org dashboard. Scan the sites column for anything red. A red flag is uptime below 99.5% in the past 30 days, an alert badge, a failed-payment marker, or a plan-change pending approval.

Most mornings the dashboard is green and the sweep takes two minutes. The two minutes are not a waste — they catch the one-in-twenty morning where something is wrong and prove the rest were clean.

If anything is red, open it. Do not assume "it will probably resolve." The fifteen-minute investigation that confirms "yes, it resolved on its own" is cheaper than the four-hour investigation when it does not.

2. Handle user-management requests in one focused window

Pick one window each day for user requests — adding a new hire, role changes, access removals.

Adding a user: use the org-level add (one canonical identity), then assign per-site roles separately. Never grant the same role across every site by default. Marketing on one site does not need Marketing on every site.

Removing a user: disable first, wait the recovery window (typically 30 days), then delete. Audit any active content owned by the disabled user before deletion — reassign before deleting the user record.

Role escalation requests: low-risk role bumps (Content Editor to Marketing Manager) are usually fine same-day. Higher-risk bumps (any role to Developer or Platform Admin) need written approval. Document the approval in the audit log.

3. Review billing on the first of every month

On the first business day of each month, open the billing console.

Confirm last month's invoice. Confirm the payment method is current and the card is not within 30 days of expiry. Confirm no site is on a plan that no longer matches its usage — over-provisioned sites can downgrade, under-provisioned sites need an upgrade conversation with the team lead.

Document any plan changes in a one-line note: which site, what change, why, who approved. The next month's review is faster when the previous month's reasoning is written down.

4. Walk the security checklist once a month

The first Monday of each month, run the security pass.

Confirm two-factor is on for every admin-tier user. Confirm no user with admin privileges has been inactive for 60+ days. Confirm the password policy is enforced (length, complexity). Confirm login throttling is active. Read the audit log for the past 30 days — look for mass deletes, unexpected role grants, or admin actions at unusual hours.

Document the pass in a one-line note: "May 1 — security pass clean, 2FA at 100%, no anomalies in audit log." That note is the artifact you point at if an external auditor asks.

A site is only as secure as the most-privileged inactive account.

5. Rehearse the restore on one site per month

Backups that are not tested do not exist.

Pick one site each month — rotate through the portfolio so every site gets rehearsed once per quarter. Open the Backups surface for that site. Pick a recent backup. Restore it to a sandbox environment, not production. Confirm the restored state matches what you expected.

Document the rehearsal: which site, which backup date, restore time, anything that did not match. If the restore fails or takes longer than the disaster-recovery commitment promises, that is the finding your monthly review surfaces — and that finding is the reason this rehearsal exists.

Cadence reference — daily, weekly, monthly

A Platform Admin's role is rhythm. The cadence table below is the minimum. Heavier portfolios add weekly billing checks and twice-monthly security passes; smaller portfolios scale the inverse.

Day-one checklist — first five things to do

Before you start running the portfolio, walk this checklist. Each item closes a gap that compounds into incident risk if left undone.

1. Confirm two-factor on your own account. Every other security commitment in this guide assumes the Platform Admin account itself is hardened. If yours is not, fix it before anything else.
2. Enumerate every site in the portfolio. One row per site: domain, plan tier, primary admin, last-activity. The list is your map for the rest of the role.
3. Read the audit log for the past 30 days. Get a baseline for what "normal" looks like across the portfolio — typical hour-of-day, typical actor, typical action type. Anomalies are only legible against a baseline.
4. Confirm the billing payment method is current and not within 30 days of expiry. Failed payment is the most preventable platform incident.
5. Identify your peer Platform Admin or successor. A Platform Admin with bus factor of one is an organization with bus factor of one. Name your successor and book the handover walk-through.

Day-two through week-two progression

The first two weeks set the baseline. Cadence beats heroics — small, repeated actions across two weeks compound into a portfolio you can hand over.

By end of week two, you have established the cadence: morning sweep · weekly user audit · monthly security pass · monthly backup rehearsal. Anyone covering for you can follow the same rhythm.

Key surfaces this role uses

Seven surfaces carry the daily work. You will not visit all seven every day, but every one of them gets touched at least monthly.

• Org dashboard. Morning sweep. Uptime. Activity. Alert badges.
• Users (org-level). Add, edit, disable, remove across every site.
• Billing console. Invoices. Payment method. Plan changes. Renewal dates.
• Audit log. Read-only history of every admin action across every site.
• Security panel. Two-factor enforcement. Login throttling. Password policy.
• Backups. Backup history per site. Restore rehearsals.
• Per-site admin. Full admin into any site in the portfolio when a site-level question needs the platform admin's eyes.

Key surfaces this role does NOT use

The surfaces below are visible to you but should not become your daily work. They belong to named roles that are not Platform Admin. Doing this work yourself blurs the audit trail and creates a "Platform Admin did everything" pattern that no successor can inherit.

• Editing blog posts or pages directly. Content Editor surface.
• Running marketing campaigns. Marketing Manager surface.
• Building or editing pages in SG-Builder. Developer or Content Editor surface, depending on scope.
• Writing or modifying Custom CSS / Custom Codes. Developer surface only. The platform-risk surface.
• Replying to customer comments as the brand. Content Editor or Marketing Manager — never Platform Admin.
• Issuing refunds. Ecommerce Manager surface.

What success looks like

A healthy state for a Platform Admin at month 12 looks like:

• Two-factor enabled for every admin-tier user. No exceptions, no temporary waivers carried for more than a week.
• Org dashboard sweep done every morning, documented in a short daily note.
• Monthly billing review summarized in one paragraph the CFO can read in 30 seconds.
• Backup rehearsal performed on every site at least once per quarter, with results documented.
• Audit log reviewed monthly with zero unexplained actions.
• One Platform Admin is not the bus factor — a peer is named and trained to run the role in your absence.

Common questions for this role

"Can I delegate Platform Admin to a junior team member?" No. Delegate the cadence (someone runs the morning sweep) but not the role. Platform Admin grants the keys to every site in the org. The role belongs to a senior owner.

"A team lead wants their entire team to have Platform Admin on their own site. Is that okay?" No. Platform Admin is org-wide. The role they probably want is a per-site admin role. Walk through the role glossary with the team lead and pick the right fit.

"How do I add a new site without going through provisioning every time?" The provisioning workflow is the audit trail. Skipping it is how sites end up off-budget and unmonitored. Streamline by templating the discovery questions you ask the requesting team — not by skipping the provisioning step.

"A site is showing uptime below 99% — what do I do?" Open the site's monitoring panel. Look at the alert history. If the drop is a single incident, document it and watch. If the drop is a pattern (recurring 5-minute outages), escalate to platform monitoring. A 99% number is roughly 7 hours of downtime in a month — most organizations expect much better.

"The CFO is asking why the bill went up. Where do I look?" Billing console → plan-change history. Most month-over-month increases trace to a plan upgrade on one site or a quota event. Both surface as line items in the invoice.

"An employee left and they had Platform Admin. What is the priority order?" Disable login immediately (do not wait). Rotate any shared credentials they had access to. Reassign sites where they were primary admin. Wait the recovery window, then delete the account. Document each step in the audit log.

What to do if it does not work

A site does not appear in the org dashboard.

The site may not be linked to the org. Confirm the site's owner is a user in your org, and the site's owner has set the org affiliation in their account settings. If the affiliation is set and the site still does not appear, contact partner support.

Two-factor enforcement is not catching a user.

The user may have an exemption set on their account. Org-wide two-factor enforcement applies only when no per-user exemption overrides it. Audit per-user exemptions monthly and remove any that are not actively justified.

The billing console shows an invoice line you cannot explain.

Open the invoice detail. Every line names a site and a charge type — base plan, plan change, over-quota event, add-on. If the line still does not explain itself, route the question to billing support with the invoice ID.

A user is reporting they cannot log in but you see no failed-login events in the audit log.

The user may be hitting the throttle. Login throttling blocks attempts before they create audit entries on some configurations. Confirm with the user which email they are using — typos in the email field are the most common cause.

A backup rehearsal fails.

That is the finding worth the rehearsal. Document the failure mode (corrupt archive, restore timeout, missing dependency). Escalate to platform support with the rehearsal log. Reschedule the next rehearsal in two weeks rather than four — confirm the issue is resolved before returning to the normal monthly cadence.

Escalation paths

Escalate when:

• A site shows extended downtime (more than 15 minutes) — escalate to platform monitoring.
• The audit log shows unexpected admin actions you cannot explain — escalate to security.
• Multiple sites in the portfolio show the same symptom — possible platform-level issue.
• A billing anomaly (charge mismatch, missing invoice) — escalate to billing support.
• A backup restore fails or runs significantly longer than expected — escalate to platform support with the rehearsal log.
• A peer Platform Admin is leaving the role and the bus factor is dropping to one — escalate to leadership to name a successor and run a handover before the existing admin departs.

Every escalation includes: site name, symptom in one sentence, evidence (audit log entry, invoice ID, screenshot), what you have already checked, and your recommended next action.

Cross-link to deeper docs

• For Content Editor — the most common role you grant to a new hire.
• For Developer — the role with the highest platform-risk surface; grant carefully.
• For Partner / Agency — if an outside agency builds or operates sites for you.
• For Marketing Manager — the role for the team running campaigns on your sites.
• SGEN Glossary — confirm platform language before writing internal SOPs.
• FAQ — short canonical answers to recurring questions.

Other roles in the organization

Each role on a SGEN site has its own onboarding guide. As Platform Admin you set the boundary inside which every other role works. Know the surfaces you are granting access to before you grant them.

Related reading

• Content Editor onboarding
• Developer onboarding
• Marketing Manager onboarding
• Ecommerce Manager onboarding
• SEO Specialist onboarding
• Support Agent onboarding
• Partner / Agency onboarding
• SGEN Glossary
• FAQ