Inputs
Outputs
Reference the chosen tag in a later block as
{{ steps.classify_text.text_classification }}.
Behavior
On each run, the block sends theInput text and your Tags list to the model, then returns whichever tag fits best. The model is limited to your list, so it never invents a category. It always returns something, though, even for vague or off-topic text. A junk input still produces a tag rather than an error.
With Allow multiple tags off, the output is a single tag. With it on, the output can hold several tags. A downstream block must then be ready to receive more than one value, so write the result to a multi-select attribute, not a single-select one.
The block only reads and computes. It does not save its result to any record or list entry. The Text classification output lives in the run until a write block consumes it. Cost is token-based, which means it scales with the amount of text the model reads. Longer inputs and longer tag lists consume more credits per run.
Gotchas
- The result vanishes if nothing saves it. The block computes a tag but writes nothing on its own. Follow it with Update record or Update list entry and map
{{ steps.classify_text.text_classification }}into the target attribute. - A select attribute drops unmatched tags. Writing to a single-select or multi-select attribute requires the option to already exist. Create the matching options on the attribute first, with names that match your
Tagsvalues exactly. Otherwise the write silently keeps nothing. - Overlapping tag definitions make the result unstable. Suppose two tags mean nearly the same thing, like
PricingandCost. The model then splits ambiguous inputs between them from run to run. Keep tag names mutually exclusive when you need one reliable answer. - You are paying the model to do a keyword match. Sometimes a fixed rule decides the tag, such as a substring, a sender domain, or a known value. In that case a free Filter or Switch does the same job for zero credits. Reserve this block for genuinely fuzzy text.
Examples
Tagging inbound form answers by pain point
A contact form asks “What’s the main problem you’re hoping to solve?” You want the free-text answer sorted into a fixed set of pain categories before you send the lead to a rep.
For the answer “We can’t get our Salesforce data to sync cleanly,” the block returns
Integrations. A following Update record writes that tag to the Primary pain attribute on the person record.
Sorting a parsed webhook field into several themes
A support tool posts ticket text to a Webhook received trigger. You first run Parse JSON to pull out themessage field. Then you classify that text into one or more themes. This way a single ticket can carry every relevant tag.
Bug and Churn risk. An Update list entry writes both into a multi-select Ticket themes attribute on the support list.