Custom Objects
| Field | Value |
|---|---|
| Audience | public |
| Page type | reference |
| Area | sg-admin |
| Updated | 2026-05-14 |
The SG-Admin Custom Objects pillar — operator-defined record types.
The Custom Objects pillar in the admin lets operators define site-specific record types beyond the platform-default set (Pages, Posts, Products, Forms, Locations, Events). Each custom object type carries its own schema, its own per-record edit surface, its own surfacing model on the public site. This page is the Reference definition.
What is this for?
Read this page when you want the structural definition of custom record types — the type model, the per-type schema, and the surfacing model.
Good use cases
- You are scoping a site that needs structured data beyond Pages / Posts / Products.
- You are explaining to a stakeholder how SGEN extends with custom types.
- You hit a "can we add a Project record type?" question.
What NOT to use this for
- Step-by-step procedures — open the relevant Guide.
- Per-release shipped change — open What's New or Changelog.
How this connects to other features
- SG-Admin Overview — parent surface.
- Custom Fields — the schema-extension mechanism per type.
- Pages — for comparison; Pages is the default page-shaped record type.
Where to find it
Open SG-Admin for the active site. Custom Objects is in the sidebar under the customization or content-types group. Type definitions and per-type record lists are both reachable from this section. Admin access is required to define or modify object types.
Definition
A custom object type in the admin is an operator-defined record type. Each type carries name (Project / Recipe / Team Member / Case Study / etc.), schema (the field set defined via Custom Fields), edit surface (auto-generated based on schema), inventory list view, and optional public-page rendering.
The defining property is operator-defined. Where the platform-default record types ship as part of the platform, custom object types are configured per site to fit site-specific structured data needs.
Purpose
Define the Custom Objects pillar as a Reference layer.
Scope
Covers the type model, the schema extension via Custom Fields, the surfacing model. Does not cover per-step procedures or per-release shipped change.
Type model
Each type is identified by name + slug. Types can carry: structured fields (per Custom Fields Reference), public-route configuration (whether the type renders as public pages), and per-type templates (where rendering is enabled).
Site · SG-Admin · Custom Objects
Type definitions
| Type name | Records | Fields | Public render |
|---|---|---|---|
| Project | 47 | 8 (custom) | Yes — /projects/$slug |
| Team member | 12 | 6 (custom) | Yes — /team/$slug |
| Case study | 22 | 10 (custom) | Yes — /case-studies/$slug |
| Internal note | 340 | 3 (custom) | No (internal only) |
Schema and surfacing
Schema for each type is defined via Custom Fields (per-type scope). Surfacing model — public route, listing patterns, detail templates — is configured per type. SG-Builder Posts blocks (or custom-object-aware blocks) can list and surface custom-object records on pages.
Constraints and boundaries
Custom Objects is a Reference area for operator-defined record types.
Do not use for: per-step procedures (Guides), per-release shipped change.
Public boundary
Public-safe.
Examples
Example 1 — Operator adds a Project record type
Operator creates a Project type with 8 custom fields (client name, project description, hero image, results summary, start date, end date, services used, testimonial). Configures public render at /projects/$slug. Editors create Project records; the public site lists them in a Projects archive at /projects. The landing page SG-Builder block shows the 3 most-recent projects.
Example 2 — Operator adds an internal-only type
Operator creates an Internal Note type with 3 fields (subject, body, assigned-to) and disables public render. Records exist in the admin for operator reference; nothing from this type surfaces on the public site. Editors use it to track per-project context notes alongside published records.
Example 3 — Operator extends an existing type
Operator adds a new Custom Field — "Campaign tag" (Select) — to the existing Case Study type. All 22 existing Case Study records carry the new field immediately, with the value empty until each record is edited. Editors fill the field as they update records for the next campaign cycle.
Documentation guidance
Use this page as the structural definition for the Custom Objects pillar.
Reading order
Open this page when scoping site-specific record-type needs. Pair with Custom Fields for schema definition.
Related reading
- SG-Admin Overview — parent surface.
- Custom Fields — per-type schema mechanism.
- Pages — comparison default record type.
Vocabulary cross-reference
- Custom object type — an operator-defined record type that extends the platform-default set.
- Type schema — the field set the type carries, defined via Custom Fields.
- Public render — whether the type produces public-facing pages at a configured route.
- Per-type template — the rendering template that controls how one custom object type displays on the public site.
- Inventory list view — the per-type list surface inside the admin that shows all records of that type.
- Operator-defined — configured per site by the operator, not shipped as platform default.
Maintenance discipline
When Custom Objects changes across releases (new type capability, new surfacing model), update this Reference.
Related reading
| Topic |
|---|
| SG-Admin |
| Custom Fields |
| Pages |