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.
A type defines a kind of object. It is the main modeling boundary in Jetstack.
Use a type when:
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.
A property defines a field, relation, or computed value on a type.
Properties are where Jetstack concentrates much of its configuration power:
Property design has outsized impact on the rest of the platform because queries, views, automations, and permissions all depend on it.
See Properties.
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.
A query defines how a set of objects is selected. It may be fully configured or based on custom SQL.
Queries are reused by:
See Queries.
A view is the default list or display experience for a query result set. It combines:
See Views.
A canvas is a custom composition surface used for pages, snippets, widgets, and property-focused experiences.
Use a canvas when:
See Canvases.
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:
See Modules.
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.
The scheduler is the time-based execution service for automations. It stores future runs, optional recurrence, skip state, and logs.
See Scheduler.
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.
A group is a shared context boundary, usually organizational rather than permission-centric. Groups can carry dashboards and homepage defaults.
See Groups.
A tenant is the deployment and operational boundary. A tenant owns:
Most governance and operator-facing chapters are tenant-focused.
An expression is a dynamic configuration value evaluated at runtime. Expressions make many Jetstack fields behavioral rather than static.
See Expressions.
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.
A filter is a runtime condition attached to a property. The actual operator set and SQL translation are property-family dependent.
See Filter Operators.
A public surface is any tenant capability intentionally exposed outside the authenticated application shell, such as:
These require more governance than internal-only surfaces.