Core Concepts
Why Terminology Matters
Jetstack is highly composable. The same object type can appear in modules, views, queries, automations, permissions, and APIs. Because of that, consistent terminology is not cosmetic. It is the difference between a coherent implementation and a confusing one.
Type
A type defines a kind of object. It is the main modeling boundary in Jetstack.
Use a type when:
- you need a new domain object
- you need a distinct set of fields and behaviors
- the object deserves its own queries, views, or permissions
A type also carries higher-level behavior such as form variants, custom canvases, default viewer, comments behavior, ACL enablement, parent module placement, and active state.
See Types.
Property
A property defines a field, relation, or computed value on a type.
Properties are where Jetstack concentrates much of its configuration power:
- visibility rules
- editability rules
- defaulting
- calculations
- masks
- validation
- filter generation
- relation semantics
Property design has outsized impact on the rest of the platform because queries, views, automations, and permissions all depend on it.
See Properties.
Object
An object is a runtime instance of a type. If a type is the schema-level definition, an object is a concrete record created from that definition.
This distinction matters because many expressions and permissions operate on objects, not on types.
Query
A query defines how a set of objects is selected. It may be fully configured or based on custom SQL.
Queries are reused by:
- views
- property selectors
- permissions
- templates and integrations
See Queries.
View
A view is the default list or display experience for a query result set. It combines:
- a target object type
- a default query
- viewer choice
- runtime state such as filters, grouping, tags, and folders
- view-specific actions and add behavior
See Views.
Canvas
A canvas is a custom composition surface used for pages, snippets, widgets, and property-focused experiences.
Use a canvas when:
- standard views are not expressive enough
- a page needs multiple visual or interactive regions
- you want widgetized or embedded experiences
- you need canvas-specific expression scope
See Canvases.
Module
A module is a navigation and entry-point concept. It tells Jetstack how a piece of functionality appears in the tenant navigation and what the primary destination should be.
Modules can point to:
- another module
- an internal app route
- an external URL
- nothing, when the module is only a grouping node
See Modules.
Automation
An automation is a configured logic flow. It reacts to events, buttons, forms, webhooks, or scheduler runs.
An automation is not only "something that runs in the background". In Jetstack, it is also the main place where business workflow, conditional branching, and external integration behavior are encoded.
See Automations.
Scheduler
The scheduler is the time-based execution service for automations. It stores future runs, optional recurrence, skip state, and logs.
See Scheduler.
Role
A role is a capability boundary. Roles do not merely label users. They determine which system actions, types, properties, views, modules, widgets, and automations are available.
Group
A group is a shared context boundary, usually organizational rather than permission-centric. Groups can carry dashboards and homepage defaults.
See Groups.
Tenant
A tenant is the deployment and operational boundary. A tenant owns:
- implementation definitions
- settings
- translations
- synchronization packages
- permanent links and routes
- secrets
- AI configuration
- runtime storage specific to that tenant
Most governance and operator-facing chapters are tenant-focused.
Expression
An expression is a dynamic configuration value evaluated at runtime. Expressions make many Jetstack fields behavioral rather than static.
See Expressions.
Scope
Scope is the set of values and objects available to an expression at evaluation time. Canvas scope and automation scope are especially important because they determine what builders can reference.
See Scope Resolvers.
Filter
A filter is a runtime condition attached to a property. The actual operator set and SQL translation are property-family dependent.
See Filter Operators.
Public Surface
A public surface is any tenant capability intentionally exposed outside the authenticated application shell, such as:
- public modules
- public canvases
- permanent links
- tenant routes
- webhooks
These require more governance than internal-only surfaces.