Getting Started with the SGEN Admin
Walk the SGEN admin on your first session, then move to real work.
The SGEN admin should feel navigable on the first session. Know where you land after login, how the sidebar is organized, what your role controls, and which actions are safe to do first. This guide is the first-session orientation for the admin surface specifically — pair it with Getting Started with SGEN for the platform-level read.
What is this for?
Read this page during your first session in the SGEN admin. It establishes where you are, what each surface is for, and what you can safely do without consequences while you learn.
Good use cases
- You received admin access and want to understand the interface before doing any real work.
- You are an editor or operator joining a team that already runs an SGEN site.
- You are a site owner who wants the orientation before handing the admin to your team.
- You hit a question like "Where in the admin do I go to add a new page?"
What NOT to use this for
- Platform-level orientation — open Getting Started with SGEN.
- Per-module reference — open the admin module reference for the specific surface (Pages, Forms, etc.).
- Build sequence — open How to Build First Site in SGEN.
Before you start
You should have:
- An SGEN admin account with at least editor-level access.
- Login credentials and the admin URL for your site.
- A vague idea of what role you will play (site owner, editor, marketing, operations).
How this connects to other features
- Getting Started with SGEN — platform-level orientation.
- How to Build First Site in SGEN — the build sequence after orientation.
- SG-Admin Overview — full admin module reference.
- Pages — the engine surface most editors work against.
Where to go
Open the admin login page (typically your-site.com/sg-admin). Log in. The first surface that loads is the Dashboard.
How to use the SGEN admin on your first session
Steps — Walk the admin
1. Land on the Dashboard
After login the SGEN admin lands you on the Dashboard. The Dashboard is the home base — recent activity, quick links to common surfaces, system status when relevant.
For a brand-new site the Dashboard is mostly empty. The value on day one is knowing where it is so you can return to it. As the site fills up, the Dashboard becomes a useful at-a-glance read of what changed recently.
The Dashboard does not require configuration. It reads from the rest of the admin and surfaces what's relevant.2. Read the sidebar
The left sidebar is the main navigation. Every module the platform offers — Pages, Posts, Forms, SEO, Analytics, Settings, Templates, Custom Fields, and the rest — is reachable from the sidebar.
Sections expand to show sub-pages where the module has more than one surface. Pages expands to show All Pages, Add New, Categories. Forms expands to show All Forms, Submissions, Reports. The expansion is consistent across the sidebar; modules with multiple surfaces follow the same pattern.
For first-session orientation, scroll the sidebar end to end. You don't need to memorize every entry; recognizing the shape is enough. The first few work sessions teach you which entries you use often.3. Confirm your role and access
Your role controls what the sidebar shows. A site owner sees every module; a marketing operator sees a subset; a content editor sees a smaller subset still.
If a sidebar entry seems missing, your account probably doesn't have access. The default reaction should be to check with whoever administers the site, not to assume the platform is broken. Most "missing" surfaces are role-based, not technical.
The role is set when the account is created and can be adjusted by a super admin afterwards. New teammates often start with editor access and gain more as they grow into the work.
4. Walk the breadcrumbs
The top of every admin surface shows breadcrumbs that tell you where you are. The breadcrumbs are clickable; clicking a parent crumb returns you up one level without hunting through the sidebar.
Breadcrumbs become more useful as work goes deeper. Editing a specific Form's submissions is three or four clicks deep; the breadcrumbs are the quickest way back to the Forms list or the Dashboard.
5. Try one safe action
Before closing the first session, try one action that doesn't change the live site:
- Open Settings, look at the values, close without saving.
- Open Pages, click into a page, look at the editor, close without saving.
- Open Media Library, upload a test image, see it appear in the library.
- Open Forms, click Add New, look at the form-creation surface, close without saving.
What success looks like
A successful first admin session looks like:
- You logged in and reached the Dashboard.
- You recognize the shape of the sidebar even if you don't remember every entry.
- You understand that your role controls which entries are visible.
- You used breadcrumbs at least once to move up a level.
- You tried one safe action without changing the live site.
What to do if it does not work
The login page won't accept credentials. Verify the URL (typically your-site.com/sg-admin), check that the password is correct, and look for any password-reset email that might have arrived. If neither works, contact whoever administers the site for a credential reset.
Some sidebar entries are missing. Almost always a role-based limitation, not a technical issue. Contact the site administrator to confirm what role your account has and whether it can be adjusted.
The Dashboard is empty. Expected on day one. The Dashboard fills up as the site does work; the empty state is not a problem.
Breadcrumbs disappear on some pages. The SG-Builder editor surface uses its own chrome and replaces the breadcrumb bar with editor controls. Breadcrumbs return when you exit the editor back to the regular admin.
The admin feels overwhelming. Common on first session. The platform is large; orientation does not require knowing every module. Walk the five core surfaces (Dashboard, Pages, Forms, Analytics, Settings) and let the rest stay quiet until you need it.
Best practices
- Save often. Use Draft while work is in progress.
- Walk the breadcrumbs to navigate; the sidebar is for jumping between modules.
- Try safe actions first. The admin doesn't punish exploration.
- Add redirects when URLs change so old links don't break.
- Test forms after publishing them — the test send and the live submission flow share the same path.
- Keep one heading style across the site so the admin's content surfaces stay tidy.
Common questions
Where do I create a new page? Sidebar → Pages → Add New. The new page opens in the editor; save as Draft until ready to publish.
Where do I find form submissions? Sidebar → Forms → Submissions. Each form's submissions are listed there; per-form filtering is available.
Where do I configure global SEO? Sidebar → SEO → Global SEO. Per-page SEO is configured on each page record.
Where do I add a redirect? Sidebar → Redirects → Add New. Each redirect is a from-URL to-to-URL pair with optional permanent / temporary toggle.
Where do I see analytics? Sidebar → Analytics. Event Logs is the raw event view; Reports is the aggregated view.
Where do I upload media? Sidebar → Media Library → Upload. Uploaded media is reused across the site by referencing it from any page or post.
Where do I configure the contact email? Sidebar → Settings → primary email field. The same value flows into form-submission notifications by default.
Core concepts that matter early
A handful of concepts come up in the admin often enough to be worth naming.
Page — a standalone site page. Created in the Pages module. Editable in SG-Builder. Has its own URL, its own SEO frontmatter, its own publishing status.
Post — an article or blog entry. Created in the Posts module. Same general shape as a Page, biased toward chronological content. Lives under /blog/ by default.
Form — a structured input surface that captures submissions. Created in the Forms module. Embedded on pages by referencing the form ID. Submissions land in the Forms admin.
Submission — one filled-out form. Stored in the Forms admin under the corresponding form. Reviewable, exportable, downloadable.
Shortcode — a reusable snippet you place inside content to display dynamic items (a form, a related-posts list, an embedded asset). Shortcodes resolve at render time.
Draft — the saved-but-not-published state. Drafts are visible in the admin but not on the live site. Useful for work in progress.
Published — the live state. Published records are visible to visitors.
Trash — soft-deleted content. Trashed records are hidden from the admin's main views but recoverable for a configurable retention window.
Why these concepts matter on day one
The concepts compose. A Page can embed a Form via Shortcode; the Form captures Submissions; a Page can be in Draft, Published, or Trash status; a Post is a Page-shape biased toward time-series content. Operators who absorb the concepts early read the rest of the admin without confusion; operators who skip them tend to ask the same questions repeatedly.
Memorizing the definitions isn't necessary. Recognizing the words when they appear in admin surfaces is enough.
What's different from other admin tools
Operators arriving from other admin platforms (WordPress, Squarespace, Wix, Webflow, custom CMSes) often expect to find similar shapes in the SGEN admin. Most are present; a few are intentionally different.
The publish step is more deliberate. Some platforms auto-save and auto-publish; SGEN saves to draft by default and requires an explicit publish action. The trade-off: more deliberate control, slightly more friction. Most operators prefer the deliberate path after the first few sessions.
Plugin-equivalent surfaces are native modules. Where WordPress would have you install a plugin for forms, redirects, popups, custom fields, or SEO, SGEN ships those as native modules. The sidebar lists them; no installation step is needed.
The editor is one editor. SGEN uses SG-Builder for both page bodies and template bodies. Other platforms sometimes have one editor for content and a different editor for templates; the consolidated editor is faster to learn but a different shape if you arrived expecting separate tools.
Settings is centralized. Site-wide settings live under one Settings module rather than scattered across multiple plugins or admin areas. Operators find what they need faster but need to know that Settings is the place to look.
Analytics is built in. No separate analytics setup is required.
Page views, form submissions, and other site events flow into the analytics module automatically.
The platform's tracking honors visitor consent state, so analytics works alongside the Tracking Consent module without per-feature wiring.
For sites that already have Google Analytics or another external analytics tool, the platform supports adding those alongside the built-in analytics — operators don't have to choose one or the other.
Backups are built in. Site backups run on a configurable schedule and are restorable from the Backups module. No external backup plugin is needed; backup-and-restore is part of the platform's surface.
Performance defaults are reasonable. Out of the box, image optimization, caching, and CDN delivery are turned on for most sites.
Operators tune them where the defaults don't fit; they don't have to assemble the performance stack.
SEO is integrated. Per-page SEO frontmatter, global SEO defaults, sitemap generation, and robots.txt management all live in the SEO module.
Multi-site is supported. Operators managing more than one site can switch between sites from the dashboard chrome without logging in and out.
The site picker remembers which site each session was last on; switching is one click.
Drafts and revisions are first-class. Every save creates a revision automatically.
Operators can compare versions, restore an earlier version, and see who changed what across the entire site history.
The platform never silently overwrites prior work; rollback is always available.
The revision history doesn't expire by default. Old revisions stay accessible until an operator deliberately prunes them.
What to expect on day two
After the first session orientation, the second session is where real work starts. Most operators report the second session feels significantly easier than the first; the orientation pays off quickly. By the third or fourth session, the admin feels familiar enough that operators stop thinking about the navigation and start thinking about the work.
A walk through the safe first actions
The first session is best spent on safe first actions — actions that let you learn the admin without consequences. A few worth doing in order.
Open Settings, look at the values, close without saving. This shows you what's already configured and lets you see the surface without changing anything. Close the tab without saving and nothing changes.
Open Pages, click into the first page in the list, look at the editor, close without saving. This shows you how a page edit works. The SG-Builder editor opens; the toolbar, the canvas, and the side panels are all visible. Closing without saving leaves the page exactly as it was.
Open Media Library, upload a small test image, see it appear. This is one safe action that does change state — the test image is stored in the library — but the change is reversible (delete the image afterwards) and doesn't affect any visitor-facing surface.
Open Forms, click Add New, look at the form-creation surface, close without saving. This shows you how forms are built. The form-builder has a similar shape to the SG-Builder editor; recognizing the pattern makes Form work easier later.
Open Analytics, look at the empty-state. The analytics surface for a brand-new site has no data yet. Looking at the empty state shows you the navigation; the data fills in as the site goes live and gets traffic.
Why safe first actions matter
The first session is for orientation, not output. Operators who try to produce real work in the first session often hit decision-fatigue (every choice has long-term consequences they aren't yet equipped to make). Operators who walk safe first actions instead come back to the second session with a clear picture of where things are and what each surface does.
The discipline is not unique to SGEN — every platform benefits from a "look before you leap" first session. The platform is large enough that the discipline matters more here than on smaller tools.
Admin interface conventions
The admin interface follows a few conventions that recur across every module.
Sidebar navigation on the left. Sidebar navigation stays visible across most surfaces; modules are grouped by area; sub-pages appear as expandable entries under their parent.
Action buttons top-right. Primary actions (Add New, Save, Publish) appear top-right of each surface. Secondary actions (Filter, Export, Bulk Edit) appear above the content area on list surfaces.
Status pills tell state. Records carry status pills (Draft, Published, Scheduled, Trash, Archived) that read at a glance. The pill colors are consistent across modules.
Search and filter inline. Most list surfaces have a search box and filter chips above the results. Search reads from titles by default; filter chips narrow by status, category, date range, or other module-specific dimensions.
Bulk actions on selected. Selecting multiple records via the row checkboxes reveals a bulk-action dropdown. Common bulk actions: Delete, Restore, Change Status, Export.
First admin session habits
The conventions above don't have to be memorized. Recognizing them when they appear is enough. By the third or fourth admin session, the conventions feel automatic and operators stop noticing them as conventions.
The platform doesn't add per-module exceptions to the conventions. Every module follows the same pattern; learning one module teaches you the shape of the others.
Roles and what they typically can do
A rough sketch of what the platform's standard roles control. The exact mapping is configurable per site; this is the default starting point.
Super admin — every surface, including user management and role assignment.
Site owner — every content and configuration surface, plus billing where applicable. Cannot manage other admins' accounts.
Editor — content surfaces (Pages, Posts, Forms, Media Library), publishing rights for content. Limited or no access to Settings, SEO defaults, role management.
Contributor — content authoring with draft permissions only. Can create and edit but cannot publish; submissions go through editor review.
Viewer / Reporter — read-only access to selected modules (often Analytics and Submissions for marketing roles). Cannot create or edit.
The role assigned to a new account governs the sidebar that account sees. If the role is wrong, an admin can adjust it from the user-management surface.
Reading order
Read this guide on your first admin session. Pair with Getting Started with SGEN for platform-level orientation, and follow with How to Build First Site in SGEN for the build sequence.
For deeper module reference after orientation, the SG-Admin Overview is the entry to the full admin module documentation.