> ## Documentation Index
> Fetch the complete documentation index at: https://docs.custral.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Concepts

> Understand the architecture and mechanics of Custral Blocks.

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

| Type         | Runs as          | Used in                                                                                                                     |
| ------------ | ---------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Embedded** | Rendered UI      | Pages, dashboards, and record layouts                                                                                       |
| **Action**   | Executed step    | [Workflows](/automation/workflows/overview), [Sequences](/automation/sequences/overview), [Jobs](/automation/jobs/overview) |
| **Trigger**  | Starting event   | The first node of a Workflow or Sequence                                                                                    |
| **Task**     | Assignable to-do | A teammate's task queue                                                                                                     |
| **Widget**   | Interactive tool | The widget bar                                                                                                              |

### Status

| Status       | Meaning                                                                                                                          |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| **Public**   | Listed in the block picker, the normal state for a usable block.                                                                 |
| **Unlisted** | Usable but hidden from the picker.                                                                                               |
| **Private**  | Not surfaced, used for retired or internal blocks that keep rendering on existing placements but no longer appear in the picker. |

## 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.

## Related

* [Blocks overview](/blocks/overview): the catalog and block types.
* [Get started with Blocks](/blocks/getting-started): add and configure your first block.
* [Workflows](/automation/workflows/overview) · [Sequences](/automation/sequences/overview): where action and trigger blocks run.


## Related topics

- [Developer Overview](/dev/overview.md)
- [Learn the Product](/start/onboarding/learn.md)
- [Standard Objects](/data/objects/standard-objects.md)
- [BI Best Practices](/bi/best-practices.md)
- [Get started with Blocks](/blocks/getting-started.md)