Aspen Builder

Last updated: September 22, 2026

What is Builder?

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

The admin opens Builder, connects to their instance, and customizes it. 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 and 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.

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

  • Picklists: Edit picklist values so users see only the relevant options for each context.

  • 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.

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

Save & Check In

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.