Use a custom field in an automation

Custom fields are most powerful when Automations read them. A “Contract Tier” field sits there as data; combined with a rule, it routes every conversation from a Tier 1 contact to the Premium team without anyone thinking about it.

Two patterns

• Read — use the field’s value as a condition that decides whether the rule runs or which branch matches.
• Write — not available yet. No automation action updates a custom field today; see Writing a custom field below.

This article covers reading.

Before you start

• The custom field exists (create one first)
• Admin permissions on Automation Rules

Read a custom field as a condition

1. Open Settings → Automation rules and open a rule, or click Add rule for a new one.
2. Under Only if, click Add condition.
3. Pick the field. Custom fields are in the field list under Custom Fields (Contact) and Custom Fields (Conversation), by the label you gave them. You can search by the label.
4. Pick the operator: is, contains, is empty, is more than, and so on. The operator list depends on the field’s type — Number fields support is more than / is less than, Select fields support is, Text fields support contains / starts with.
5. Set the value. For Select fields, pick the option from the dropdown.
6. Click Save changes (or Create rule for a new rule).

You can also ask the assistant, for example “Only for contacts whose Contract tier is VIP.”

Example — route VIP contacts to the Premium team:

• A new conversation starts — Contract tier (Custom Fields (Contact)) is vip — Assign conversation to an agent or team → Premium

Writing a custom field

Automations can’t write a custom field yet. An action that updates contact fields exists in the model but is marked coming soon, so the action picker doesn’t offer it and a rule saved with it never fires.

Until then, a custom field gets its value in one of these ways:

• Agents edit it on the record. For a multi-select field with Agents can also type their own values turned on, agents can add their own values next to the configured options.
• The API sets it through customFields when creating or updating a contact. The API doesn’t check a Select value against the field’s options, so send the option’s slug yourself.

Common patterns

• Tier-based routing. Pick your contract-tier field from Custom Fields (Contact), branch on tier, assign to different teams. See the VIP routing recipe — it does this with the built-in customer level, but the pattern translates directly to a custom-field tier.
• Auto-tagging by product. Pick your product-category field from Custom Fields (Conversation), add a matching tag.

Verify it worked

1. Build the rule, set conditions to match a known test record.
2. Open a test conversation / contact / case that matches.
3. Trigger the rule (manually if needed via Manual run, or by replicating the triggering event).
4. Open Run history for the rule. The run should show success.
5. Open the affected record and confirm the rule’s action took effect (for the routing example, the conversation is assigned to the Premium team).

Troubleshooting

• Symptom: Condition matches the wrong records or nothing. Fix: Confirm you’re comparing against the value (slug), not the label. Settings → Custom Fields → field → Options shows both.
• Symptom: There’s no action to update a custom field. Fix: None exists yet. See Writing a custom field for the ways a field gets its value today.
• Symptom: The custom field doesn’t show up in the condition picker. Fix: Confirm the trigger type can see that entity’s fields. The field picker offers only the fields that the trigger can fill.

See also

• Conditions and operators reference
• Actions catalogue
• Auto-populate from conversation content with Sidekick