Article 10: Aspen Builder

Last updated: September 16, 2026

What is Builder?

Aspen Builder is a native desktop application that gives an admin a point-and-click interface for administering their Aspen CRM instance. It can be downloaded from the Aspen Admin Console.

The admin opens Builder, connects to their instance, and administers it through a UI: browse and edit metadata, onboard and manage employees, define permissions, create workflows, and create triggers. Changes are validated before they land, so an admin can make edits safely without a developer.

A technical admin who also works with Claude Code and the aspen CLI operates against the same instance. Builder reconciles with that path; the two do not conflict.

Objects

Objects is the primary work area in Builder. The Objects Home lets the admin browse and search the instance's objects; both standard platform objects (_p) and custom objects (_c).

All object-based metadata is edited in the context of its parent object. Each component type below lives under its parent object's view:

  • Fields: Create and edit data fields on an object. Controls field subtype, display name, and whether it's required.

  • Layouts: Define record detail layouts; the arrangement of fields users see when viewing or editing a record. Admins may allow user overrides.

  • List Views: Configure how records are listed; columns shown, sort order, and filter conditions.

  • Object Types: Create and edit subtypes of an object, allowing different behaviors or field sets under the same parent object.

  • Picklists & Filters: Edit picklist values and set per-object filtering so users see only the relevant options for each context.

  • Relationships: View and configure relationships between objects. Relationships are represented through fields and are editable on their own tab.

  • Lifecycles & Workflows: Define the states a record moves through, transitions between those states, entry criteria, field behaviors, and allowed actors.

  • Search Config: Toggle an object as searchable, choose display and secondary search fields, and set exclusion filters.

  • Triggers: View and configure record triggers attached to an object.

Builder highlights locked metadata that cannot be edited, hides system fields by default, and flags core platform objects (standard p), which carry higher and different restrictions than the custom objects (c) the admin creates. For example, custom required fields on CRM objects like Contact are blocked on platform objects.

The admin can view any component as raw JSON from any metadata screen. This is useful for understanding the underlying structure or cross-referencing with CLI output.


Save & Deploy

Builder separates saving from deploying. Edits write to the local file system first. The admin can accumulate several changes, review them together, and deploy as a batch.

Deploying to a production instance requires explicit confirmation. Each deploy targets whichever instance is currently selected in the instance picker.

Schema reconciliation

When Builder connects to an instance, or the admin switches instances, it reconciles its local files against the instance's current metadata and schemas. This ensures the admin always edits against what's actually deployed, not a stale local copy.

Schema definitions for platform objects (for example contact_p and account_p) aren't part of the customer JSON source. Builder downloads and caches those schemas locally from the instance so it can view, validate, and edit against them correctly.

Concurrent edits

Edits apply against the latest metadata on the instance. If a component the admin is working on was changed separately, by another admin or a developer deploy, that component is locked and the admin must start over from the latest version. There is no silent merge.

No migrations

Aspen runs a single declarative schema per instance with no migrations. The platform computes the path from the current deployed schema to the desired one; validations gate that transition. A change that passes on a developer instance can still fail on production if deployed code there differs.

Validation

Builder catches problems at two points: as you edit, and again at deploy. Both run against real platform endpoints, giving the admin the same guardrails as a code-first deploy.

When changes have been checked in, confirm the changes have been made in the web app.