Platform Overview

What It Is

Jetstack is a configurable platform for building business applications inside a tenant. Instead of hardcoding a complete application for each use case, you define a reusable model and let the platform assemble the runtime behavior from that definition.

In practice, Jetstack combines:

  • an object model layer built from types and properties
  • a data access layer built from queries and filters
  • a presentation layer built from views, modules, and canvases
  • a logic layer built from automations and scheduler tasks
  • a governance layer built from roles, permissions, groups, users, translations, and tenant settings
  • an integration layer built from REST, MCP, webhooks, AI tooling, and operator-focused utilities

What It Is Not

Jetstack is not only:

  • a CRUD generator
  • a website CMS
  • a standalone workflow engine
  • a thin UI shell over SQL tables

Those things may appear inside the platform, but the platform itself is broader. It is closer to an implementation framework where model, UI, logic, access, and operations stay connected.

Why It Matters

Jetstack becomes valuable when a tenant needs:

  • multiple object types with relationships
  • configurable forms and list experiences
  • dynamic business rules without custom code for every rule
  • role-aware access and object-aware permissions
  • reusable navigation and public entry points
  • operational lifecycle support such as translation, versioning, and sync

The Main Building Loop

A typical implementation follows this loop:

  1. Define types.
  2. Add properties.
  3. Create queries that express useful object sets.
  4. Expose them through views or canvases.
  5. Place them in navigation through modules.
  6. Add automations and schedules.
  7. Secure everything with roles, permissions, and settings.

That loop is repeated throughout the product.

The Runtime Model

Jetstack's runtime is shaped by a small set of repeated concepts:

  • model definitions describe what the tenant contains
  • runtime state describes how users are currently filtering, viewing, grouping, or acting on that model
  • evaluation engines turn configuration into live behavior
  • operator surfaces control rollout, governance, and diagnostics

This matters because many fields in Jetstack do not behave as static text. They are evaluated through expressions, scope resolution, permission logic, or filter translation at runtime.

Architectural Layers In Practice

Data Model Layer

This is where types and properties live. It defines the structure of the tenant and the meaning of stored values.

Access And Retrieval Layer

This is where queries, filters, grouping, calculations, tags, and folder context live. It defines what data a user or integration is working with.

Interaction Layer

This is where views, modules, canvases, forms, and actions live. It defines how users experience the model.

Logic Layer

This is where automations, scheduler tasks, and event-driven behavior live. It defines what happens when work is performed or when time passes.

Governance Layer

This is where roles, permissions, groups, versions, sync, translations, customization, and app settings live. It defines who can do what and how the tenant is operated.

Integration Layer

This is where REST, MCP, webhooks, AI agents, sidecar services, and advanced tools live. It defines how Jetstack participates in a larger system landscape.

How The Codebase Reflects The Platform

The codebase exposes the platform surface mainly through:

  • resource types under app/model/ActiveResource/ResourceTypes
  • property family implementations under PropertyTypes
  • presenter surfaces under app/Presenters
  • shared runtime services under app/model/libs
  • API modules under app/api
  • AI sidecar runtime under ai-sidecar

You do not need to read those files to use the platform, but this documentation uses them as the source of truth for platform behavior.

Example

A procurement tenant might contain:

  • Supplier, Contract, Request, and Invoice types
  • properties describing status, amount, owner, and document references
  • queries for draft approvals, expiring contracts, and overdue invoices
  • views for buyers, approvers, and finance
  • modules for Procurement, Contracts, and Administration
  • automations for assignment, approval escalation, and reminders
  • permission queries that limit who can edit financial records

Each of those pieces is configured separately, but they work because they share the same underlying platform model.

What To Learn Next

After this chapter, the most important next concepts are:

Previous← Navigation And Surface MapNextIntroduction →