Platform

Semantics, Structure, and Security.

Three layers behind the platform: a relationship-centric CRM data model, a git-based build you compile yourself, and permissions enforced down to the field and record level.

01 · semantics

The data model, ready to extend.

Aspen ships with 3 types of objects - People, Work, and Custom. Each object is connected by relationship objects like Contact_Role or Employee_Role. Tailor them to your business by extending them with custom fields, objects, and states.

people, work, and the objects that connect them
contact_role owns champion Ada Chen contact Acme Corp account Opportunity #142 $84k · negotiation
states & lifecycle · opportunity
qualify demo negotiation won
✕ qualify → won · illegal transition, rejected at write
FeatureWhat it isWhy it matters
8 core objects Contact, employee, lead, account, opportunity, case, and the relationship objects that connect them. A relationship-centric CRM data model from day one — not a legacy schema with downstream consequences.
40 objects, ~200 fields Every core object ships with supporting objects, 8 system fields, and roughly 200 predefined application fields across the model. The fields real CRMs need already exist — you're extending, not starting from zero.
Custom fields, objects & object types Add the custom fields, objects, and object types your company needs on top of the core model. Small teams keep it simple; larger teams make it as robust as they need.
States & lifecycles Define states and lifecycles per object, with legal transitions enforced. An opportunity can't skip a stage or land somewhere it shouldn't — by construction, not convention.
Contact_Role & Employee_Role Dedicated relationship objects connecting people (contact, employee) to work (lead, account, opportunity, case). Relationships between people and work are modeled explicitly, not bolted on with generic lookups.
Aspen Miner Connect to your company's email and calendar systems to automatically create, manage, and clean contacts in Aspen. Sales teams should focus on closing deals, not managing their contacts.
Workflows & Rust triggers Simple logic is added definitionally, via workflows. Complex logic runs as native triggers written in Rust. You reach for code only when you actually need it.
Open data model The full Aspen data model is published and available to all. Easy to view, easy to update, and easy to extend.
02 · structure

Metadata in git, compiled by you.

Check out the Aspen metadata, edit in Aspen Builder or Claude Code, compile it in Aspen, and deploy using CI pipelines — the same workflow your engineering team already uses without fumbling through changesets.

git repo
metadata/objects
metadata/workflows
metadata/triggers/*.rs
diff · review · revert
ac compile
types checked
triggers verified
permissions linked
✓ metadata valid · ready to deploy
deploy
test instance
production instance
promote when ready
↕ your choice of tooling Use Aspen Builder's desktop app, or the Claude Code plugin — custom triggers and UI code work the same either way.
FeatureWhat it isWhy it matters
Aspen Builder A cross-platform desktop app for checking out Aspen metadata, browsing, and editing metadata locally. One tool covers every OS your team runs — no server-side-only tooling.
Aspen Compiler Compiles and validates metadata — types, triggers, and permissions — before it ships. Mistakes get caught at compile time, not in production.
Git-based check-in Metadata is checked into git as part of the normal build — diff, review, and revert like any other code. Your schema gets the same change history and review discipline as your codebase.
Claude Code plugin & CLI tools Work entirely from Claude Code if you prefer, or any IDE, for custom triggers and UI code. No proprietary editor required — use the tools your team already has open.
Four API classes Data (AQL query language and CRUD), Describe (what the running user or agent can see), Metadata (system config, permissioned), and Devtools (instances, check-in, compile, project moves). Every layer of the platform — not just the data — is reachable by API.
people
app · mobile
agents
api
permission sets, assigned to profiles
permission sets sharing rules profiles field-level security
your data · secured at every level
✓ profile: AE → opportunity.amount visible
✕ profile: SDR → opportunity.amount hidden · field-level rule
03 · security

Enforced by permission sets, for people and agents alike.

Permission sets and sharing rules control access at the object, record, and field level. They're assigned to user profiles — and profiles are assigned to people and agents the same way.

FeatureWhat it isWhy it matters
Permission sets Reusable bundles of access, assigned to user profiles. Configure access once per profile, not per user.
Sharing rules Row-level rules that extend or restrict record visibility beyond the object default. Control exactly which records a person or agent can see, not just which objects.
Profiles for people and agents Profiles are assigned to users or to agents — the same mechanism governs both. Agent access isn't a separate, bolted-on permission model — it's the one your admins already know.
Object, record, & field level security Security can be scoped as broadly as a whole object or as narrowly as one field. You get exactly the granularity a given piece of data needs — no more, no less.