Use a custom field in an automation

Custom fields are most powerful when Automations read and write 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 fires or which branch matches.
• Write — use the field as an action that updates the value on the conversation, contact, or case.

This article covers both.

Before you start

• The custom field exists (create one first)
• Admin permissions on Automation Rules
• For Select fields: know the option’s machine slug (the value, not the display label) — find it in Settings → Custom Fields → field → Options

Read a custom field as a condition

1. Open Settings → Automation Rules and create or edit a rule.
2. In the Conditions section, click Add condition.
3. Pick the field path. Atender’s condition picker exposes custom fields as:
   contact.custom_fields.<key> for contact custom fields
   conversation.custom_fields.<key> for conversation custom fields
   case.custom_fields.<key> for case custom fields The <key> matches the auto-generated machine key on the field, not the display name.
4. Pick the operator: equals, contains, is empty, greater than, etc. The operator list narrows based on the field’s type — Number fields support greater than/less than, Select fields support equals, Text fields support contains/starts with.
5. Set the value. For Select fields, this is the option’s slug, not its label.
6. Save.

Example — route VIP contacts to the Premium team:

• Conversation created — contact.custom_fields.contract_tier equals vip — Assign team → Premium

Write a custom field as an action

1. In the Actions section of a branch, click Add action.
2. Pick Update custom field (or the entity-specific equivalent: Update conversation field / Update contact field / Update case field, depending on UI version).
3. Pick the field key.
4. Set the value. For Select fields, pick from the option list. For Text/Textarea/Number/Date, type or template the value (merge tags from the conversation context are supported, e.g. {{contact.email}}).
5. Save.

Example — auto-populate escalation_reason when an SLA breaches:

• SLA breached — (none — every breach gets the tag) — Update conversation field → escalation_reason = sla_breach

Common patterns

• Tier-based routing. Read contact.custom_fields.contract_tier, 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. Read conversation.custom_fields.product_category, add a matching tag.
• Synthesizing summary fields. When a case closes, write a resolution_summary field with templated values from the conversation context for analytics later.
• Capturing escalation context. When a rule escalates a conversation, write the reason into a custom field so future agents can see why it was escalated, not just that it was.

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 Manual Executions for the rule. The action should show success and the field’s new value.
5. Open the affected record. The field’s value should match.

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: Action sets the wrong value. Fix: For Select fields, the value must be one of the configured option slugs. Anything else is rejected. For Text fields with merge tags, confirm the merge tag resolves — empty contact fields produce empty values.
• Symptom: The custom field doesn’t show up in the condition picker. Fix: Confirm the trigger type can see that entity’s fields. A Tag added trigger on a contact tag won’t expose case fields, for example.

See also

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