Attio: automate customer follow-up and make every step inspectable
Attio organizes companies, people and deal progress into customer records, then automates updates, assignment and notifications. Run history helps teams trace what one follow-up did and where it stopped.
Form your own approach first, then explore the reasoning to check trade-offs and validation you may have missed. There is no single right answer.
How should a panel explain continuing versus rerunning?
Scenario
Design a “continue after failure” panel for your own customer follow-up tool. A CRM stores customer and follow-up records. A run is one customer-triggered workflow; an attempt is one execution made to resolve that task. This is your design exercise, not a request to copy Attio.
Known conditions
- Original workflow V1 has three steps: A creates a follow-up task, B assigns an owner and C sends an internal notification. A and B definitely succeeded; C definitely failed and the service confirms it sent nothing. A’s task still exists. Unknown network outcomes are out of scope.
- V2 is now published with different notification text, and the customer’s owner changed from Lin to Zhou. Continuing from the failed step uses V1 and the original confirmed inputs. Rerunning the current workflow starts at A with V2 and current customer data. It may create a duplicate task; the system neither deduplicates automatically nor undoes the old task.
- User X only wants the original notification sent to Lin. User Y wants the new owner and text used. Before execution, show the version, data point in time, start step and effects that already happened. Allow only one retry in progress.
Walkthrough and deliverables
Explain the different choices X and Y should make. Sketch selection, confirmation, running and completed/failed states. Write the primary-button and risk text, and show the relationship between attempts one and two. Propose two observation tasks to test whether users understand that rerunning does not undo earlier work; do not invent results.
Explore the reasoning
- Separate goals first. X needs C under the old inputs. Y needs V2 and the current owner, but must first decide how to handle the existing task. Three vaguely named retry buttons are insufficient.
- Summarize four differences before confirmation. Show V1/V2, old/new owner, start step and actions that will run again. Keep A’s existing task visible rather than erasing it from the story.
- Give Y a prerequisite check. Ask how the existing task will be handled or let Y defer the rerun. Do not assume the new flow deduplicates. A generic risk warning without naming the repeated action is unhelpful.
- Retain attempts and request state. Prevent repeated submission while running. After completion, show the actual second result with access to the first. Failure also retains the selected scope and version; a successful click is not a sent notification.
- Observe both goals. Ask participants to perform X and Y’s tasks and state their expected recipient, text and task count. Record accidental use of the new version, assumptions that old tasks were undone, and confusion between running and complete. Use those observations to revise the panel.