Skip to main content
To get the most out of blocks, it helps to understand the three pillars that define them: Blocks, Parameters, and Providers.

​
1. Blocks

A Block is the definition of a piece of functionality. It carries the metadata Custral needs to place, configure, and run it. Key attributes:
  • Key: a unique identifier (e.g. custral.database.table), matched byte-for-byte between the backend definition and the frontend component.
  • Name: the display name shown in the picker and the UI.
  • Icon: the visual used across the platform.
  • Type: the block’s category, which decides where it appears and how it runs.
  • Status: controls whether the block shows up in the picker.

​
Type

​
Status

​
2. Parameters

Parameters are a block’s configuration options. They let you tailor a block to a specific use case without changing its definition. For example, the Create Record action block exposes parameters for:
  • Object: which type of record to create.
  • Template: an optional record template to pre-fill fields.
  • Property List: the initial field values to set.
And the Table embedded block exposes:
  • Object: which records to show.
  • Fields: which columns to display.
  • Calculations: an optional per-column sum, average, min, max, or count.
Each parameter has a type (text, number, object, property, dropdown, user, and so on), can be required or optional, and can carry a default. In automations, a parameter can be mapped to dynamic data (a value from the triggering record or the output of an earlier step), using tokens like {{first_name}}.

​
3. Providers

A Provider is the entity that owns and serves a block. Every provider is one of three kinds:
  • Custral (internal): the first-party blocks built into the platform. Every block whose key begins with custral. (tables, charts, actions, triggers, tasks) comes from the Custral provider.
  • Integrations (pre-built): connected third-party services can contribute their own blocks. Connect Stripe and you gain “Charge Customer” and “Create Invoice” actions; connect GitHub and you can link a pull request to a record; connect Google Meet or Microsoft Teams and you get meeting blocks.
  • Your organization (external): apps built on Custral’s developer platform can register their own blocks.
This provider model is what lets Custral surface the right blocks based on the integrations you’ve connected. A Stripe block only appears once Stripe is connected.

​
Block lifecycle

When a block is used (added to a page or wired into an automation) Custral manages it through three phases:
  1. Discovery. The block picker lists the blocks available to you, based on your connected providers and installed modules.
  2. Configuration. You set the parameter values for this specific instance.
  3. Execution. At runtime the block is either rendered (embedded blocks) or executed (actions and triggers) using its configuration and the live context around it.

​
Composability

The power of Custral is that blocks are composable. Embedded blocks stack into dashboards and record layouts, action blocks chain together in workflows and sequences, and a task block can be created by an action block. You compose existing blocks rather than reinventing functionality for every new solution.