All posts

Attio call outcome mapping: a safe writeback contract

Published

Ryan Erkal

Ryan Erkal
Founder, Redialler

Style 2 title card with Ryan Erkal beside the words Attio call outcome mapping

Attio call outcome mapping works best as a small writeback contract: define what the rep selects, choose the exact Person or list-entry field, validate its type and options, then attach the next action separately. A call outcome describes what happened. A lifecycle stage describes where the record sits. A task or suppression rule describes what happens next.

1. Separate outcome, stage and next action

Start by naming the three things your map must keep apart. A call outcome is the result of one attempt, such as No answer or Callback. A lifecycle stage is the record's broader position, such as New, Working or Qualified. A next action is a task, date or suppression decision that tells someone what to do.

Combining these into one field creates ambiguous reports. A callback is a call result and an owed task. It is not automatically a new lifecycle stage unless your team has chosen that meaning. A Do not call request is a suppression instruction. It must not be treated as a normal lost stage that remains eligible for another campaign.

Write the contract in one sentence before you create fields: “Each call gets one outcome; only explicit business rules change stage; each follow-up or exclusion has its own action record.” This gives reps a short decision path and gives an admin something testable.

Close outcome design guidance

2. Map the outcome to the right Attio field

Decide whether each value belongs on the Person record, the list entry, or both. Person attributes travel with the contact across lists. List-entry attributes describe the contact's state in one particular list. For a call from a campaign list, it can be useful to store the last outcome and stage on the entry while keeping first and last contact timestamps on the Person.

Attio's People documentation lists phone_numbers as a Person attribute. Its list-entry API addresses a specific list and entry_id, which is a reminder that the same person can have different list context. Do not write a list value to a Person field just because the labels look similar. Verify the parent object, record ID, list ID and entry ID together.

A practical four-row contract looks like this in prose. No answer writes the no-answer call result and leaves stage unchanged unless your policy says otherwise. Callback requested writes Callback, records the explicit due date on the list entry when that field exists, and creates one linked task. Wrong number writes Bad number, pauses the suspect number from callable work immediately, routes the record for correction, and preserves the evidence. Do not call writes the opt-out result and activates durable suppression; it is not simply a negative stage.

Attio People attributes

Attio list-entry updates

Calling with Attio

3. Check field type, options and permissions

Before rollout, inspect the live Attio schema. A text field accepts free text, while a select or status field accepts only the options configured for that field. A multiselect has different update semantics again. Attio documents that PATCH appends multiselect values, while PUT can overwrite or remove them. A mapping that assumes overwrite can leave stale values behind.

Check that the field is writable and that the integration has the scopes it needs. Attio's record update reference calls out record_permission:read-write and object_configuration:read. List-entry updates use list_entry:read-write and list_configuration:read. A token can be valid while a particular field is read-only or a select option has been removed.

Redialler reads the current object or list attributes before a write and filters unknown or read-only values. Its broader CRM adapter validates a configured outcome field as writable text, select or status and checks the selected option. That prevents a silent label mismatch, but it cannot decide which field your team intended. Keep a mapping table with field slug, type, allowed values, owner and last review date.

Attio person update reference

Attio rate-limit guidance

4. Give non-identical outcomes different handling

No answer means the intended person was not reached, so it should not advance a stage that requires a conversation. Busy is a provider or network signal that the line was occupied. Left voicemail means the rep knows a message was left. Connected means a call leg connected, but your team should define whether that includes an IVR or voicemail connection. The provider status and the business outcome answer different questions.

Interested and Not interested describe a conversation and can drive different stage or qualification rules. Callback requested needs an exact date and timezone, plus an owner or an explicit unassigned state. Wrong number needs a data-correction path. Do not call needs suppression before the next queue is built. A task that says “do not call” is not a reliable substitute for the exclusion check.

The FTC says covered telemarketing callers must maintain entity-specific do-not-call procedures and honour a consumer's request not to receive further calls. It also says state and FCC requirements can apply. Treat the mapped outcome as an input to that process, then verify that the suppression source is checked before a dial.

Twilio call status reference

FTC telemarketing guidance

5. Preserve record identity and make retries idempotent

Bind every write to the record selected before the call. Store the Attio object and record ID, and store the list and entry IDs when the call came from a list. Re-check that the selected number still belongs to that record before writeback. A name or a phone search can find a candidate; it does not prove that a later retry should write to that candidate.

Idempotency means repeating the same operation reaches the same final state without creating a second note or task. Use a stable call ID or operation marker. For a callback, search the linked record's open tasks for that marker before creating a task. For a note, reconcile the marker and record binding before updating or creating. If a create response is uncertain, inspect the CRM first and stop when more than one matching marker exists.

Rate limits are a separate retry case. Attio says a 429 request was not processed and can be retried after Retry-After. A timeout after a create request does not prove that nothing was created, so treat it as uncertain until the record or marker is checked.

Attio list-entry update reference

Attio rate-limit guidance

6. Test one controlled record before rollout

Choose one test Person and, if relevant, one test list entry. Record the expected field changes for each of the four rows. Run No answer first, confirm that only the intended outcome fields change, then test Callback with a real future date, owner and task. Check Wrong number and Do not call in a controlled process that verifies the exclusion bucket before any next dial.

Review the resulting record and entry separately. Check the field value, field type, option spelling, timestamp, task link and owner. Run the same save or retry request again and confirm that it does not create a duplicate. Then test a controlled permission failure and confirm that the job reports attention instead of claiming success.

Keep the mapping table under change control. When an Attio admin renames an option, changes a field type or archives a list, pause the writer, refresh metadata and rerun the one-record acceptance check. For a complete workflow, pair this guide with the linked guide about calling contacts in Attio.

How to call contacts in Attio

Discuss your calling workflow

Explore Redialler

Sources and review

Reviewed 2026-09-08. Product details and provider policies can change.

All posts