🍂Type of Components
Canonical index for every shipped component family. The old bullet list is not coverage. Each family page below is the long reference. This page stays an index plus the controls that apply to every component.
How-tos (Metric Card, Media Gallery, Status Timeline, Unique ID Chip, sections/stepper, validation, prefill) stay short and link here or to the family page.
What this is / when to use it
A component is one block on a screen: a heading, a field, a button, a comments thread. Pick the family from the job, not from the Notion property name.
When not to add a component: if the user needs a different screen (a list, a queue, a content page), add a screen. Components do not replace Select Items or Work Queue.
Before you start
You are on a details, form, update list, or content screen. Native automation screens use their own builder sections, not this palette.
The Notion property exists if the component reads or writes data. See Notion property types.
You know whether the block is view-only or an input.
Build it (shared)
Open the screen.
Add component. Choose a type. You can switch types later with the type switcher when the new type accepts the same property.
Bind Input property / View property when the block is data-backed.
Set required, default, disable editing, and visibility (tables below).
Copy/paste logic if you need the same visibility or default on another field.
Preview, then publish.
Every control (shared)
These appear on almost every data component. Family pages list type-specific enums.
Label
Text
User-visible name.
Property
Sheet field
Notion property the component reads or writes.
Required
On / off
Empty value blocks submit. Independent of format validation.
Disable editing
On / off
Show the value without allowing change (update forms / update lists).
Default value
NONE / EXACT / DYNAMIC (CURRENT_USER)
Prefills create forms. Exact is a literal. Dynamic current user writes the logged-in user into a people/user/text field.
Copy / paste logic
Clipboard in builder
Copies visibility and related logic, not the property binding.
Type switcher
Compatible types
Change Text → Long text without losing the property when the field type allows it.
Section + stepper (form layout) lives on Form (Add Item). The how-to stays a short job.
What users see
View components render the current Notion value (or empty). Input components render a control; on submit they write the property if it is writable. Hidden components are not shown and do not collect input.
Limits and plans
One component per property is the usual pattern. Two inputs bound to the same property fight on submit.
Read-only Notion types still accept a view component. An input bound to formula/rollup will not write. See the field map.
Comments, HTML block, and page content have their own plan/moderation notes on those pages.
Example
A Create Form Add request uses: Heading, Text (title, required), Long text (details), Options dropdown (priority), User (assignee, default CURRENT_USER), File upload (attachment), Button (cancel URL), and submit actions documented on the form-actions page.
Fix problems
Required error on a hidden field
Visibility hides it but required is on
Unset required, or keep the field visible.
Prefill ignored
Update form, or param name mismatch
Prefill is Create Form only. Match the param.
Related
Open the family page that matches the component you are adding. Next on the maker path after fields: Component visibility and Screen Actions.
Last updated