State Component

The State component offers exactly the options a Status column allows, and nothing else. It is the only form component whose choices come from your data model rather than from the form.

Use it wherever a record moves through stages: request stages, approval outcomes, ticket states, pipeline steps.

How it gets its options

You do not type the options into the form. You bind the component to a Status column, and the column's Status Group supplies them, with their names, their colours and their order.

That indirection is the point. Add a stage to the group and every form bound to it offers the new stage, with no form to republish. Rename a stage and it is renamed everywhere at once, including on submissions already collected — because the row stores a reference to the option, not its text.

Settings

The trap

The submission stores the option's identifier, not its name. Read a submission back — in an automation, a script node, or through the API — and the field holds an id. Comparing it to "Approved" will never match, and it will not raise an error either: the comparison is simply false, every time.

This is the single most common cause of an approval automation that runs and quietly does nothing. Branch on the option's identifier, or use a node that resolves the option for you.

If the field says there are no states

The component is bound to a column that is not a Status column, or to a Status column whose group has no options yet. Both show as an empty selector rather than an error.

Fix it in the table, not the form: make sure the column's type is Status and that its group actually has states defined.

Next

• Praxsuite Forms: Components Overview

• How to Create States From Scratch

• Datatypes in Praxsuite

• Boolean Component

• Logic Nodes