SGEN data model overview

In short. SGEN organizes content in five layers: site → content type (page, post, or custom object) → fields → relationships → taxonomies. Pages are for singular navigation-anchored content, posts are for time-ordered feeds, and custom objects are for everything else — directories, catalogs, portfolios. The same model scales from a one-page brochure to a thousand-product catalog without changing shape.

On this page: Pages, posts, and custom objects · Fields · Relationships · Taxonomies · Anti-patterns · Connected pages

The five layers

Every SGEN site is built from the same five layers. A request to publish, edit, or display content always touches all five — even when the screen you are looking at only exposes one of them.

Layer 1 — The site. The outermost container. A site has a domain, a brand, a navigation, a theme, and a set of users with permissions. Every other piece of content lives inside exactly one site. The site is the unit of brand and the unit of billing.

Layer 2 — The content type. Inside a site, content is sorted into types. SGEN ships three families: pages (singular, navigation-anchored documents), posts (time-ordered, feed-friendly content), and custom objects (operator-defined types for everything else — directories, catalogs, portfolios).

Layer 3 — The fields. Every content type has a set of fields. A page has a title, a slug, a body, an excerpt, SEO meta, and a featured image. A post adds author, published date, category, and tags. A custom object has whichever fields the operator defines.

Layer 4 — The relationships. Content connects to other content. A post belongs to a category. A case study links to a service. These connections are explicit, queryable, and durable — changing a relationship is immediately reflected on every front-end query that walks it.

Layer 5 — The taxonomies. Categories, tags, and operator-defined taxonomies group content for navigation, filtering, and search. A taxonomy is a controlled vocabulary that content attaches to.

Pages, posts, and custom objects — when to pick which

The most common modeling question on SGEN is "should this be a page, a post, or a custom object?" Picking right up front saves cleanup later, but content types are convertible so no choice is permanent.

Pick a page when the content is:

• Singular and stable — one of it, it does not roll over weekly.
• Navigation-anchored — lives in the header, footer, or a deliberate URL like /about.
• Hand-authored — every page gets individual attention, not a template fill-in.

Pick a post when the content is:

• Time-ordered — newest entries are usually most relevant.
• Feed-friendly — shows up in a list, paginated, on its own index page.
• Author-attributed — each entry has a clear author and published date.

Pick a custom object when the content is:

• Structured — each entry has the same fields filled in.
• Numerous — dozens, hundreds, or thousands of entries.
• Queried by attribute — visitors filter by location, price, category, or date.

The pattern: pages are for unique, navigation-anchored content. Posts are for time-ordered feed content. Custom objects are for everything in between — directories, catalogs, portfolios, archives.

Fields — what attaches to what

Fields are attached to a content type, not to an individual record. When you add a field to the "case study" custom object, every case study gets that field — existing ones with an empty value, new ones with a fresh blank. Removing a field does not delete the values inside it; the values persist in the record so re-attaching the field later loses nothing.

Fields are typed. A text field cannot hold an image; an image field cannot hold a number. Picking the right field type at creation time saves migration work later and makes front-end queries reliable.

Fields are queryable. A custom object with a "city" field can be filtered by city. A post with a "featured" toggle can be filtered to only the featured ones. Every list, archive, and search page walks fields directly — no glue code required.

Relationships — how content connects to other content

Relationships are first-class, not glue text. A case study points to a service. A product belongs to a manufacturer. SGEN models these connections explicitly — not as plain text in a body field — so when content moves, the connections move with it.

A relationship has two ends: the owner (the content that initiates the connection) and the target (the content being pointed at). You decide whether it goes one way or both ways. When you set up a bidirectional relationship, a service can list every case study that points at it without any extra configuration.

Taxonomies — how content groups for navigation and filtering

Two taxonomies ship by default with posts: categories (usually hierarchical, small in number) and tags (usually flat, large in number). Categories sort the broad shape; tags add specific texture.

Custom taxonomies extend the pattern. A directory of locations can have a "region" taxonomy. A course catalog can have a "level" taxonomy. Each behaves the same way: content attaches to terms, the front end queries by term, the navigation renders by term.

A walked example — modeling an agency portfolio

An agency wants to publish case studies. Each has a client name, service area, publication date, outcome summary, hero image, and body. Case studies should be filterable by service area and should link to the service detail page.

In the SGEN model:

• Layer 1 — the site is the agency's domain.
• Layer 2 — "case study" is a custom object. Posts hold the blog. Pages hold the homepage, about, and service detail pages.
• Layer 3 — case study fields: title, slug, client name, hero image, publication date, outcome summary, body, SEO meta.
• Layer 4 — a reference field "applied service" points at the service detail page. Each service page can be queried for the case studies pointing at it — the bidirectional view.
• Layer 5 — a "service area" taxonomy (branding, web, growth, ops) lets visitors filter the case studies index.

The front end then renders three views without custom code: a case-studies index (filterable by service area), a single case-study detail page, and a "related case studies" block on each service detail page.

For migration modeling — reshaping an existing archive of posts and pages into the SGEN model — see the Migration guides.

Edge cases worth knowing

Many-to-many relationships (a product belonging to multiple categories) are supported — use a reference field that allows multiple values. Deep chains (4+ hops) usually signal a missing intermediate type.

Sparse fields — a custom object where most entries fill in 5 of 50 fields — signal that the type should split.

Anti-patterns worth naming

Pages used as posts. A blog built as fifty hand-authored pages with publication dates in the title works once and does not scale. Fix: convert to posts and use the built-in archive views.

Posts used as catalog records. A product directory built as posts with attributes packed into the body cannot be filtered by those attributes. Fix: convert to a custom object with typed fields.

Custom objects with one field. A "tag" custom object for a list of terms that could have been a taxonomy adds overhead for no benefit. Fix: collapse to a taxonomy.

Modeling everything as pages. Operators coming from page-centric platforms sometimes model posts, custom-object records, and taxonomy terms as standalone pages. The site works on day one and grows unwieldy by day thirty. Fix: identify what is genuinely page-shaped (singular, navigation-anchored) and convert the rest.

The shortest possible summary

SGEN content lives in a site. A site has content types (pages, posts, and operator-defined custom objects). Content types have fields (the data). Content connects to other content through relationships. Content groups for navigation and filtering through taxonomies. The same five layers cover every shape of site.

Connected pages

This concept doc sits in the architecture cluster. The four siblings cover the surrounding ground:

• Multi-Site Architecture Overview — how the same data model extends across a portfolio of sites without bleed.
• Extensibility Overview — how custom objects, fields, and integrations combine to extend the model.
• Permissions and Roles Overview — who can edit which content types and which fields.
• Performance and Caching Overview — how the model's queries stay fast.
• SGEN Glossary — definitions for content type, field, taxonomy, relationship.