SGEN extensibility overview

In short. SGEN extensibility works as a five-rung ladder: Custom Fields (extra data on existing types) → Custom Objects (new content types) → Automations (logic inside the platform) → Webhooks (events out to another system) → Integrations (bidirectional bridge). Pick the lowest rung that solves the problem. That's the whole model.

On this page: The five-rung ladder · Custom fields · Custom objects · Automations · Webhooks · Integrations · Walked example

The five-rung ladder

The SGEN extensibility model is the set of paths an operator takes when the out-of-the-box shape does not fit. The five paths form a ladder — lower rungs handle smaller stretches; higher rungs handle bigger ones. The choice is almost always "what is the lowest rung that solves my problem?" because every rung up adds capability and adds responsibility.

Rung 1 — Custom fields. Add a field to an existing content type. A page gets an "above-the-fold callout" field. A post gets a "featured" toggle. Custom fields stay inside the existing model.

Rung 2 — Custom objects. Define a new content type for content that does not fit pages or posts. A catalog of products. A directory of locations. A library of case studies. Custom objects sit alongside pages and posts as first-class shapes.

Rung 3 — Automations. Define a rule that runs inside SGEN when something happens. A new contact form submission sends a notification. A status change on a custom object record fires an email. Automations stay inside the platform — no external system required.

Rung 4 — Webhooks. Send an event out of SGEN to another system. When a contact is created, a webhook fires to the CRM. When a post is published, a webhook fires to the search index. Webhooks are one-way: they tell another system what happened in SGEN.

Rung 5 — Integrations. A two-way bridge to another platform. SGEN sends data out, receives data in, and both sides stay in sync. A single business case often climbs more than one rung — a product catalog might use custom objects (rung 2), automations (rung 3), a webhook to inventory (rung 4), and an integration to the CRM (rung 5). Each rung handles a different layer of the same case.

Custom fields — the smallest stretch

Custom fields extend an existing content type. They are the right answer when the data fits inside something that already exists.

Custom fields are typed. A text field cannot hold an image. The type is picked at field-creation time and decides which input the editor sees, which validation runs at save, and which queries can walk the field on the front end.

Adding a custom field is a single decision: which content type does it attach to, what is the field name, what is the field type. Once added, every record of that content type carries the field — existing records start with an empty value.

Removing a custom field does not delete the underlying values. The values stay in the record, hidden from the editor, until the field is re-attached. Renaming a field by removing and re-adding preserves data if the re-attach happens in the right order.

Custom objects — when fields are not enough

Custom objects are the right answer when the data has its own shape. A custom field on the post type can carry a "spec sheet" attachment; a custom object lets you model "spec sheet" as its own thing — with its own fields, its own records, its own relationships.

Three signals say a custom object is the right call.

The data has more than three or four fields of its own. A product is not a post with a price; it has a name, a SKU, a price, a description, an image, an availability status, a category, and a relationship to a manufacturer. That much structure belongs in its own content type.

The data shows up in many places. A team member appears on the team page, in the leadership section, on a case study byline, and in a search filter. The team member is its own thing — a custom object that other content references.

The data is queried by attribute. Visitors filter by city, by category, by date range, by price tier. A page with the data baked in cannot be filtered; a custom object can.

The admin treats a custom object like a first-class content type. The permission model gates it. The front end renders an index page, a detail page, and filter-driven views from the same record set.

If the case does not fit a custom object, a custom-field shape on an existing content type is usually the right alternative. A custom object can be converted back to a custom-field shape, and a custom-field shape can be promoted to a custom object, with data preserved across the move.

Automations — when something has to happen on its own

Automations run inside SGEN. They are the right answer when an event in one part of the platform should cause an action somewhere else in the platform — without an operator clicking through the steps.

An automation has three pieces.

The trigger. What happens that sets the automation running — a contact form submitted, a post moving to published, a record's status field changing, a scheduled time arriving.

The condition. What has to be true for the automation to run. Optional — a trigger without a condition runs every time.

The action. What the automation does — send an email, set a field, notify a teammate, tag a contact, create a record.

Webhooks — when something outside needs to know

Webhooks are the path out of SGEN. When something happens inside the platform that another system needs to know about, a webhook sends the event over.

A webhook has three pieces: the event (which SGEN action fires it), the destination (a URL belonging to another system), and the payload (a structured record of the action, the affected record's identifier, the timestamp, and the operator who did it).

Webhooks are one-way. They tell another system that something happened in SGEN; they do not bring information back. For two-way sync, see integrations.

Webhooks include a delivery log. Failed deliveries are visible. Retries happen on a schedule — an operator does not have to find out from the other system that a webhook has not been arriving.

Integrations — when both sides need to stay in sync

Integrations are the path for a bidirectional bridge. SGEN sends data out, the other platform sends data in, and both sides hold the same record.

Three classes cover the common business case.

Identity and audience integrations. CRMs, email platforms, customer-data platforms. The shared record is usually a contact or a customer. Sync runs near-real-time with a periodic full-sync fallback.

Analytics and reporting integrations. Warehouses, dashboards, BI tools. SGEN ships event data out; the warehouse handles long-term aggregation.

Operations integrations. Workflow tools, project trackers, communications tools. Posts move through workflow stages; SGEN sends and receives status updates.

Integrations carry the most operational weight. Both sides have to be configured. Authentication has to be maintained. Conflicts — what if both sides change the same record at the same time? — have to be resolved. The rule: start with the smallest path and upgrade when the case requires it. A one-way webhook often covers what looks like a full integration need.

Walked example — agency adding a directory of locations

The need. An agency's client runs a regional service business with thirty office locations. Each location has an address, hours, a phone number, a manager, a photo, a list of services, and a relationship to the parent region. Visitors filter by region and by service.

The agency chooses the rungs that fit. Rungs 1 and 2 are obvious. Rungs 3, 4, and 5 ride along as the case needs them — none are mandatory.

Common mistakes in the first six months

Climbing one rung too high. An automation inside SGEN would handle a form-submission notification without any external dependency. Reaching for a webhook instead creates a third-party service to monitor, an extra credential to manage, and a relationship to maintain.

Building a custom object that should have been custom fields. If the data lives inside a single page — an FAQ list, a feature comparison — a repeater field on that page beats a separate content type.

Setting up a full integration before the data needs to flow both ways. The integration's overhead pays off only when both sides need to stay in sync. Start with a webhook; upgrade when both directions have events.

A quarterly review of the extension catalog — every custom field, custom object, automation, webhook, and integration — catches the ones that have outlived their use.

Permissions and portability

Every extension lives inside the permission model. A custom object is governed by the same two-layer gate as a built-in content type. Custom fields inherit the permission of the content type they extend. Automations run with the identity of the operator who configured them. Webhooks and integrations carry credentials visible to administrators.

A custom role scoped to "edit case studies" lets its members edit the case-study custom object without access to other content types. Extensibility and permissions compose cleanly.

Full detail: Permissions and Roles Overview

Data portability. Every content type — built-in or custom — exports to a structured file. Custom field definitions, automation configurations, webhook configurations, and integration setups export as human-readable configuration. The data belongs to the operator.

Connected pages

• Data Model Overview — the underlying model that custom fields and custom objects extend.
• Permissions and Roles Overview — how custom roles fit the permission gate.
• Performance and Caching Overview — how custom-object queries and automation actions interact with the cache.
• Multi-Site Architecture Overview — how extensions travel across a portfolio of sites.
• Integration Patterns — the four integration shapes (pull, push, bidirectional, embed) in depth.
• SGEN Glossary — definitions for custom object, webhook, integration, and related terms.