SG-Modules

First-class features across SGEN — not plugins, not bolted on, shipped with the platform.

SG-Modules is the feature layer your team uses every day. Blog. Pages. Forms. Popups. Custom Objects. Events. Custom Fonts. Ecommerce. Integrations. Webhooks. Each module is a first-class part of the platform — it ships with SGEN, it updates with SGEN, and it shares the same admin chrome, the same data model, and the same publishing pipeline as every other module.

This page is the Reference definition of the pillar. It explains what SG-Modules is, why first-class matters, which modules are included today, and how the pillar relates to SG-Core, SG-Admin, SG-Builder, and SG-Dashboard. Per-module capability detail lives in the dedicated module Reference pages.

What is this for?

Read this page when you want the structural definition of SG-Modules — what the pillar covers, how it sits in the four-pillar SGEN model, and what distinguishes a SGEN module from the plugin-style feature pattern operators carry over from other CMS platforms. It is the entry-point Reference for everything else inside the SG-Modules section.

The page is a Reference definition. It does not walk you through how to use any individual module. Step-by-step procedures live in Guides. Per-module capability detail lives in the corresponding module Reference page — Blog, My Forms, Custom Objects, Ecommerce, Integrations, and so on.

Good use cases

• You are new to SGEN and want to understand what the modules layer covers before opening any individual module.
• You are evaluating SGEN against a WordPress-plus-plugins or Squarespace-plus-apps stack and need the structural framing for SGEN's modules.
• You are scoping a site rollout and need to know which modules ship in the platform, which are configurable per site, and which you will reach for first.
• You are explaining to a stakeholder why SGEN does not have a plugin marketplace and what fills that role instead.
• You are reading a sibling pillar page (SG-Core, SG-Admin, SG-Builder, SG-Dashboard) and want to understand where SG-Modules fits inside the same operating model.

What NOT to use this for

• Step-by-step procedures for using any individual module — open the relevant Guide.
• Per-module capability detail (fields, settings, edge cases) — open the corresponding module Reference page.
• Decisions about which subscription tier exposes which module — see the pricing surface and the Billing reference.
• Migration mapping from a specific plugin to a SGEN module — open the Migration section.
• Marketing claims about SGEN's positioning — sgen.com is the marketing surface; this page is the docs surface.

How this connects to other features

• SG-Core Overview — the platform spine SG-Modules runs on (settings, users, billing, authentication).
• SG-Admin Overview — the runtime shell every module lives inside.
• SG-Builder Overview — the visual editor that composes the page-rendered output of several modules.
• SG-Dashboard Overview — the account-tier surface that reports across modules and across sites.
• Shared Concepts — cross-platform models the modules depend on (site context, environment separation, ownership).
• SGEN Glossary — terminology source of truth for every product pillar.

Before you start

You do not need to "start" anything to read this page — it is a Reference definition, not a procedure. To use any individual module, you need a SGEN site, an active account with access to the per-site /sg-admin/ shell, and a role with permission for the module you want to open. Permission and role detail lives in the admin reference.

Where to find it

The SG-Modules layer is exposed inside the admin on every site. Open /sg-admin/ on the site you are working on and look at the left navigation — every entry in the main navigation that is not Pages, Settings, or Tools maps onto a SG-Module. The exact navigation labels match the module names listed below.

Definition

SG-Modules is the layer of SGEN that provides the daily-driver features for a site — content publication, lead capture, commerce, engagement, and operational extension — as first-class platform features rather than as plugins.

A SGEN module:

• Ships with the platform. You do not install it, license it from a third party, or wait for a vendor update.
• Shares the same admin chrome as every other module. Same left navigation. Same form patterns. Same permission model.
• Reads and writes the same data model. A custom field added to a content type is visible to forms, exports, integrations, and reports.
• Publishes through the same pipeline. Drafts behave the same way across modules. Revisions behave the same way. Publishing is an explicit operator action, not a side effect.
• Updates with the platform. Module behavior changes through SGEN releases — never through a separate "module marketplace" you have to monitor.

SG-Modules is distinct from SG-Core, which owns the platform spine underneath the modules. It is distinct from the admin, which is the runtime shell the modules live inside. It is distinct from SG-Builder, which is the visual page composer that some modules use to render their output. And it is distinct from SG-Dashboard, which is the account-tier surface that aggregates across modules and across sites.

Purpose

The purpose of this page is to define SG-Modules as the first-class feature layer in SGEN, distinguish it from the plugin-stack pattern operators carry over from other CMS platforms, and provide a stable Reference point for reading the rest of the SG-Modules library.

The page sits at the entry point of the SG-Modules section. Per-module Reference and Guide pages descend from here; this page is the structural definition the rest of the section assumes.

Scope

This page covers SG-Modules at the Reference level — the pillar as a structural part of the SGEN platform rather than as a list of every feature in detail.

The page covers:

• The first-class definition (what makes a SGEN module different from a plugin).
• The modules currently shipped in the platform.
• The relationship between SG-Modules and the other three pillars (SG-Core, SG-Admin, SG-Builder, SG-Dashboard).
• The shared admin chrome, data model, publishing pipeline, and permission model that every module inherits.
• The boundary against external services (where webhooks and the Integrations module fill the gap the plugin marketplace fills on other platforms).

The page does not cover:

• Per-module fields, settings, or step-by-step usage — those live in the module Reference and Guide pages.
• Subscription-tier exposure of modules — pricing and entitlements live in the Billing reference.
• The internal architecture of any module — that is platform-engineering documentation, not customer documentation.
• Migration mapping from specific plugins on other platforms to SGEN modules — those live in the Migration section.

Why first-class matters

The plugin-stack pattern on legacy CMS platforms ships a small platform core and a large universe of independently authored plugins. Each plugin has its own update cadence, its own data model, its own security posture, and its own conflict surface against every other plugin. The result over time:

• Compounding conflict surface. Each new plugin can break each existing plugin. Operators learn to dread updates.
• Update friction. Updating one plugin can cascade into broken pages elsewhere. Operators delay updates to avoid the cost; the delay becomes a security risk.
• Inconsistent data. A form plugin stores submissions one way; a CRM plugin reads them another way; a reporting plugin sees something else again. Operators spend hours reconciling.
• Inconsistent UI. Each plugin ships its own admin pattern. Operators relearn the surface every time they touch a different feature.
• Inconsistent permissions. Plugins implement roles independently. Granting an editor access to one module accidentally grants them access to settings on another.
• Plugin overhead. Real money. Real time. Real maintenance burden.

SG-Modules removes the layer. The features are still there — blog, forms, popups, ecommerce, custom content types, integrations — but they live inside the platform rather than alongside it. The trade-off is that SGEN modules cover the surface a serious operator needs and not every niche use case a plugin marketplace ships. Where a specific niche is required, the Integrations module and the Webhooks module bridge to external services rather than installing a foreign plugin into the platform.

The decision SGEN makes is: ship fewer features that all behave the same, instead of more features that each behave their own way.

The modules included today

Each module below is a first-class part of the platform. Each has its own dedicated Reference page; this list is the inventory and one-paragraph orientation.

Blog

The publishing module — posts, categories, tags, scheduled publication, revisions, and the editorial workflow. Built for teams that need to ship content on a cadence without arguing with the editor. Posts render with the same theme and component library as Pages, so a blog post and a marketing page look like they came from the same site. See: Blog Reference.

Pages

The static content module — landing pages, marketing pages, product detail templates, evergreen content. Pages are the most common record type composed inside SG-Builder. The Pages module owns the record (metadata, slug, visibility, publication state); SG-Builder owns the visual composition for each page. See: Pages Reference.

Forms (My Forms)

The lead-capture and data-collection module — visual form builder, field validation, file uploads, conditional logic, submission inbox, and the integration outbound that sends submissions to email, CRM, or webhook endpoints. Forms are reusable: a single form definition can be embedded on multiple pages, and submissions land in one inbox. See: My Forms Reference.

Popups

The on-page conversion module — exit-intent, time-on-page, scroll-depth, and click triggers. Popups can contain a form, a call-to-action, an announcement, or a custom layout. Popups respect the same theme and component library as the rest of the site, so the popup design matches the page rather than looking like a foreign overlay. See: Popups Reference.

Custom Objects

The structured-content extension module — your own content types beyond posts and pages. Build a Project, a Recipe, a Venue, a Course, a Property listing — each with its own fields, archive page, and detail template. Custom Objects share the same publishing pipeline, the same revision behavior, and the same access permissions as posts and pages. See: Custom Objects Reference.

Events

The scheduled-engagement module — events with start and end times, registration, capacity limits, and visitor reminders. Events can be free-of-charge or paid through the Ecommerce module. Event records render with the same theme and component library as the rest of the site. See: Events Reference.

Custom Fonts

The typography extension module — self-host typefaces beyond what the Google Fonts integration covers. Use Custom Fonts when you need a specific axis, variable instance, or licensed family that the Google Fonts catalog does not host. Custom Fonts loads through the same global typography panel as the rest of the design system. See: Custom Fonts Reference.

Ecommerce

The commerce module family — Products (catalog, variants, inventory, images), Orders (order processing, fulfilment, refunds), Coupons (discount codes with rules), and Ecommerce Configuration (shipping zones, tax rules, payment processors). Ecommerce records share the same fields, theme, and publishing pipeline as the rest of the platform. A product page is a Page rendered with product fields, not a foreign storefront grafted on. See: Ecommerce Reference.

Integrations

The external-service routing module — connects SGEN modules to outside platforms (email, CRM, automation, analytics, ad networks). Integrations are configured per site; module data flows out through configured integration endpoints rather than through plugins inside the site. The Integrations module is also where the live-claims for which third-party services SGEN currently supports are tracked. See: Integrations Reference.

Webhooks

The event-emission module — emits structured event payloads when records change inside SGEN (form submission, order placed, post published, custom object created). Webhooks let teams wire SGEN into automation tooling and into systems SGEN does not directly integrate with. Webhooks are the structural answer to "what about this niche tool that does not have a SGEN integration?" — emit the event, let the niche tool consume it. See: Webhooks Reference.

Operational modules

A small set of modules sits at the operational tier — Custom Fields (extend any content type with structured fields), Redirects (301 / 302 URL management with bulk import), Search and Replace (bulk content updates across the database), Phone Taps (tap-to-call tracking events for mobile visitors), Blacklist (block abusive IPs and suspicious user agents). These modules are less daily-driver and more "the platform needs to do this thing serious operators expect." See the per-module Reference pages for detail.

How SG-Modules sits with the other pillars

SGEN has four product pillars. SG-Modules is the daily-driver feature layer; the other three pillars define the platform around it.

Relationship to SG-Core

SG-Core is the platform spine — settings, users, billing, authentication. SG-Modules runs on SG-Core. Every module reads user identity from SG-Core. Every module respects the permissions SG-Core defines. Every module honors the per-site settings SG-Core owns. SG-Core is the layer you do not see directly when you work in a module; it is the layer that makes the module behave correctly inside your site.

If SG-Core changes (for example, a new permission tier ships), every module updates with it — operators do not need to migrate each module's permission setup independently. This is one of the core benefits of the first-class pattern.

Relationship to the admin

SG-Admin is the runtime shell every module lives inside. When you open /sg-admin/ on a site and click into Blog, you are inside the admin operating on the Blog module. The left navigation, the form patterns, the table interactions, the modals — all of that is SG-Admin chrome. The module supplies the records and the module-specific fields; SG-Admin supplies the surface.

This is why the experience of using one SGEN module feels like the experience of using any other. The chrome is the same. Operators who have learned the Blog module already know how to navigate the Forms module, the Ecommerce module, and any new module SGEN ships.

Relationship to SG-Builder

SG-Builder is the visual page composer. Some SG-Modules render their output through SG-Builder; others have native admin UI only. Pages and Custom Object detail pages compose in SG-Builder. Blog posts open in SG-Builder for the body layout. Product detail pages compose in SG-Builder. Forms, by contrast, have a dedicated form-builder UI inside the Forms module — SG-Builder is the page composer, not the form composer.

The rule of thumb: if a module renders a page on the public site, SG-Builder composes that page. If a module produces a different type of output (a form, a webhook payload, an integration push), the module has its own native admin UI.

Relationship to SG-Dashboard

SG-Dashboard is the account-tier surface — one Dashboard per customer organization, every site under it. SG-Dashboard aggregates across modules and across sites. Total form submissions across your portfolio. Total orders across your stores. Total Phone Taps across your sites. SG-Dashboard does not edit records in any module; it reports on them and routes operators into the right per-site SG-Admin to do the work.

This is the inverse boundary of SG-Admin. SG-Admin is per-site, day-in-the-module. SG-Dashboard is multi-site, look-across-the-portfolio. Modules live in the admin; their roll-up lives in SG-Dashboard.

The shared model — what every module inherits

The first-class pattern means every module inherits the same model from the platform. The list below is what is true of every module without the module having to opt in.

Same admin chrome

Every module surfaces inside the admin shell. Same left navigation pattern. Same form patterns (label above input, validation inline, save-and-close in the top right). Same table patterns (filters at top, bulk actions on selection, row-level actions on hover). Same modal patterns. Operators who learn one module's UI already know how the next module's UI behaves.

Same data model

Custom Fields are platform-level — when you define a custom field on a content type, every module that touches that content type sees the field. A form can submit to a custom field on a Custom Object. A blog post can carry custom fields surfaced in archives. An integration can map a custom field into an outbound payload. The data model is one model, not one per module.

Same publishing pipeline

Drafts, revisions, scheduled publication, and visibility states behave the same way across modules. A draft blog post and a draft Custom Object both honor the same draft-versus-published rule. Revisions behave the same way (per-post revision history is exposed in the same UI pattern). Scheduled publication uses the same picker. There is one publication concept across the platform, applied to every record type.

Same permission model

Roles defined in SG-Core apply to every module. An Editor role granted access to Blog cannot, by accident, also gain access to Settings. A Marketing Manager role granted access to Popups and Forms gets exactly that scope. Adding a new module to SGEN does not require operators to revisit every existing role; the new module respects the existing role definitions.

Same versioning and update path

Modules update with the platform. When SGEN releases, every module updates in lockstep. There is no "Blog 3.4 is compatible with Forms 5.1 but not Forms 5.2" matrix to maintain. The compatibility surface is one surface — the platform version.

Same boundary discipline

Every module respects the same boundary against the other pillars. Records and module-specific settings live in SG-Modules + SG-Admin. Visual page composition lives in SG-Builder. Account-tier reporting lives in SG-Dashboard. Platform spine concerns live in SG-Core. No module crosses these boundaries — features land where their shape matches.

Steps — how to choose between modules

This Reference is a concept page, but the question "which module do I reach for?" comes up often enough to deserve a procedure. Follow this when you are scoping a new piece of work and unsure where it belongs.

1. Identify what you are producing

Name the output. A blog post (Blog module). A landing page (Pages module). A lead-capture surface (Forms module, embedded on a Page). A scheduled gathering (Events module). A discount on the storefront (Ecommerce — Coupons). A new content type you do not see covered by posts or pages (Custom Objects). An on-page conversion overlay (Popups). A connection to an external system (Integrations or Webhooks).

If you can name the output cleanly, the module choice is usually obvious. If you cannot, the work is probably composed across two or more modules — keep reading.

2. Identify what is composed and what is shared

Some work composes across modules. A landing page (Pages) that hosts a lead-capture form (Forms) that triggers an automation (Integrations) is three modules cooperating on one outcome. This is normal. The shared data model means each module hands off cleanly to the next; you do not need to plumb the connections manually.

Identify the lead module — the one that produces the visible output (the landing page in the example above). Compose inside the lead module; reference the supporting modules from there.

3. Identify whether you need a custom content type

If your work fits posts or pages, use them. If it does not (you are tracking properties, venues, recipes, projects, events that need richer fields than Events provides), open Custom Objects. Define the custom content type once in Custom Objects; from then on it behaves like any other content type — composable in SG-Builder, exportable, surfaced in reports, addressable by forms and integrations.

Resist the temptation to fit a non-post-non-page concept into the Blog module by adding categories that act as content types. Custom Objects exists for exactly this case.

4. Identify whether an external system is in play

If the work needs to hand off to an external system (email service, CRM, automation tool, ad network, analytics destination), open the Integrations module. If the external system does not have a SGEN integration, fall back to Webhooks — emit the event from the relevant module, consume the event in the external system through the automation tool you already use.

5. Confirm permission and role coverage

Before assigning the work, confirm the operator who will do it has the role permissions for every module involved. The SG-Core permission model is module-aware; granting Blog access does not grant Forms access. If a role needs adjustment, open the admin Roles surface and adjust there once — the change applies across every site the role covers.

What success looks like

After reading this page, you should be able to:

• State in one sentence what SG-Modules covers and how it differs from a plugin layer.
• Name the modules currently shipped in the platform.
• Place SG-Modules correctly against the other three pillars (SG-Core, SG-Admin, SG-Builder, SG-Dashboard) without needing to re-read this page.
• Decide for a new piece of work which module is the lead and which are supporting.
• Explain to a stakeholder why SGEN does not ship a plugin marketplace and what fills that role instead (Integrations + Webhooks for external services; Custom Objects + Custom Fields for niche content types).

If any of the above is unclear, the answer is in the linked sibling Reference pages, the glossary, or the per-module Reference. The single best follow-up if you want depth is to read the Integrations and Webhooks Reference pages — they cover the boundary between SG-Modules and external services where most "but what about this plugin?" questions resolve.

What to do if it does not work

This page is a Reference page, so the failure modes are about understanding rather than about a broken feature. Common confusions and how to resolve them:

Examples

Example 1 — Landing page with a lead-capture form

A marketing operator is launching a campaign. They open the Pages module, create a new Page, compose the layout in SG-Builder. The Page needs a lead-capture form, so the operator opens the Forms module, builds the form, and embeds it on the Page. The form is configured to send submissions to email and to the CRM via the Integrations module. Three modules cooperate; the operator drives the work from the Pages module (the lead module — the visible output).

When a visitor submits the form, the data lands in the Forms inbox and pushes to the CRM. Custom fields defined on the form are visible to the integration without separate configuration. The integration push is recorded in the Forms submission record so the operator can see whether each submission reached the CRM.

Example 2 — Property listings on a real estate site

An agency is building a site for a real estate client. Posts and pages do not cover property listings — properties have address, price, bedrooms, bathrooms, square footage, listing agent, gallery, and so on. The agency opens Custom Objects and defines a Property content type with all of those fields. From then on, Property records compose in SG-Builder like any other page, surface in archives, are addressable by forms ("inquire about this property"), and are exportable through the Integrations module.

The agency did not install a plugin. They did not learn a new admin UI. The Property record behaves the same way every other record on the platform behaves — same admin chrome, same publishing pipeline, same revision behavior, same permissions.

Example 3 — Storefront promotion with a popup

An ecommerce operator wants to run a holiday promotion. They open the Ecommerce module and configure a Coupon (15% off, valid for two weeks, minimum cart $50). They open the Popups module and configure an exit-intent popup announcing the promotion with the coupon code. The popup is scoped to the storefront pages only. When the promotion ends, the operator disables both the coupon and the popup — two clicks, two modules, no plugin uninstall.

The popup and the coupon share the same theme and the same component library as the rest of the site, so neither looks like a foreign overlay. The promotion is reported in the Ecommerce sales rollup; the popup engagement is reported in the Popups module. SG-Dashboard surfaces both at the account tier.

Example 4 — Stakeholder asks "where's the SEO plugin?"

A stakeholder migrating from WordPress asks where the SEO plugin lives. The operator explains: there is no separate SEO plugin in SGEN. SEO is a property of the platform — every page, post, custom object, and product carries SEO fields (title, description, slug, canonical, social card) as first-class fields. The fields are visible in the relevant module's record editor. Where structured-data schemas are needed, they are emitted by the platform at render time, not by a plugin.

The stakeholder's follow-up — "but what about the niche SEO audit features I had?" — routes through Integrations (connect to an external SEO audit tool) or through the platform's own audit and reporting surfaces in SG-Dashboard. There is no plugin to install, and there is no plugin compatibility matrix to maintain.

Example 5 — Operator wants a feature SGEN does not ship

An operator wants a "loyalty rewards" feature their previous platform shipped as a plugin. SGEN does not ship a loyalty rewards module today. The structural answer: use Custom Fields and Custom Objects to model the loyalty points; use Webhooks to emit events when points change; use Integrations to push to an external loyalty platform if a specialized service is needed.

This is the boundary in action. SGEN covers the surface a serious operator needs and does not try to ship every niche feature as a first-party module. The Integrations + Webhooks + Custom Objects combination is the structural answer to the niche question, and it is consistent regardless of which niche the operator hits.

Documentation guidance

Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — new modules land inside the existing inventory section, and the relationship-to-other-pillars sections should rarely need to change because the four-pillar model is structural.

Procedural instruction belongs in Guides; shipped updates and release-specific module changes belong in What's New or Changelog. Per-module capability detail lives in the corresponding module Reference pages, not here.

Reading order across the section

Open this Overview first to anchor the SG-Modules model. Then descend into the per-module Reference pages in the order that matches your work — content modules first (Blog, Pages, Custom Objects), then conversion modules (Forms, Popups), then commerce modules (Products, Orders, Coupons, Ecommerce Configuration), then integration modules (Integrations, Webhooks), then operational modules (Custom Fields, Custom Fonts, Redirects, Search and Replace, Phone Taps, Blacklist).

The per-module Reference pages can be read in any order; this Overview is the structural assumption every module page leans on. Guides for each module layer on top — task-shaped procedures with each Guide assuming the module Reference is already understood.

Where SG-Modules appears on the live docs site

The SG-Modules section in docs.sgen.com mirrors the same structural shape documented here. Top-level navigation lands on this Overview; the per-module Reference and Guide pages descend from there. Cross-links between SG-Modules Reference, the sibling pillar overviews (SG-Core, SG-Admin, SG-Builder, SG-Dashboard), and Shared Concepts follow the boundary discipline laid out in this page.

Related reading

• SG-Core Overview — the platform spine SG-Modules runs on.
• SG-Admin Overview — the runtime shell every module lives inside.
• SG-Builder Overview — the visual editor that composes page-rendered module output.
• SG-Dashboard Overview — the account-tier surface that aggregates across modules and across sites.
• Shared Concepts — cross-platform models the modules depend on.
• SGEN Glossary — terminology source of truth for every product pillar.
• Integrations Reference — the boundary against external services.
• Webhooks Reference — the structural answer to "what about this niche tool?"
• Migration section — mapping from plugin-stack platforms onto SGEN modules.

Vocabulary cross-reference

• SG-Modules is the canonical pillar name. Hyphenated, capital G. Plural — the pillar is a set of modules, not a single module.
• Module in SGEN means a first-class platform feature, not a plugin. The word is reserved for SG-Modules entries; do not call non-module surfaces "modules" in customer-facing copy.
• First-class means shipped with the platform, updated with the platform, sharing the platform admin chrome and data model. The opposite is plugin-style — independently authored, independently updated, independently styled.
• Plugin is reserved for the pattern on other CMS platforms. SGEN does not have plugins. If a docs reader uses "plugin" to refer to a SGEN module, gently correct the term in support replies — the distinction is structural, not cosmetic.
• Integration refers to a connection to an external service through the Integrations module. Distinct from a module — an integration sends data out; a module is the feature inside SGEN.
• Webhook refers to a structured event payload emitted by SGEN to an external URL when a record changes. Distinct from an integration — webhooks are event-driven, integrations are configured connections.
• Custom Object refers to a user-defined content type beyond posts and pages. Always two words, capitalized.
• Custom Field refers to a structured field added to a content type. Always two words, capitalized. Plural is Custom Fields (the module name).