1. Product introduction

Customer follow-up beyond spreadsheets and chat

Attio is a customer relationship management tool, or CRM. It organizes companies, people and deals into records so a team can see who owns the follow-up, where it stands and what happens next. Its workflows connect repetitive actions: when an event occurs, update records, create tasks or notify colleagues according to conditions.

A small studio might enrich a new inquiry, assign an owner and then send an internal notification. A problem anywhere along the chain can look like “the owner never received the notification.” A failure badge alone does not tell the team whether to fix data, change a condition or retry delivery.

Trace one customer task to its execution before choosing a retry scope. Retrying does not undo existing tasks or notifications; business-result inspection is a suggested step. Enlarge for detail.

2. Core workflow

Give a business event an execution trail

Imagine a studio receiving an inquiry: a workflow enriches the customer details, assigns an owner and sends an internal notification. The workflow overview explains how events and conditions connect record updates, tasks and notifications. Each step has a different business result; “the workflow ran” cannot describe them all.

Workflows are available across plans, but running them uses workspace credits. Define the trigger, affected records and actions first so the later history has a clear result to check.

Follow this run when a notification does not arrive

  1. Locate the run. In the Runs viewer, find the relevant time and customer record. Look at the workflow used then and the branches it actually followed.
  2. Inspect step data. Trace the problematic step's input back to earlier outputs. Not every step has an output, so judge each according to its responsibility.
  3. Separate generation from saving. For an AI agent, inspect the tools it called and the credits used. The block reference explains that agent output does not automatically update attributes: a later update action must save it to the customer record.
  4. Confirm what has already happened. Details and ownership may already be correct while only the notification failed. Establish this before deciding whether another run could create duplicate tasks or messages.

The run diagram connects the general configuration to one customer's task. Step data then turns “no notification” into a specific, checkable cause.

Choose a retry that matches the problem

Attio distinguishes restarting from the beginning, continuing from the failed step and retrying with the current published workflow. New attempts remain under the same run for comparison. Using the current workflow preserves the original trigger details, while other data may use current values. The trigger block must remain the same and its configuration must be compatible with the original trigger information; a different trigger cannot simply stand in for the old one.

Trying again therefore need not reproduce the original inputs, and it does not undo completed business actions. Correcting data, editing the workflow and retrying solve different problems. Check the customer record, tasks and recipients afterward. The useful result is an explanation of what happened and why, not merely a green status.

3. Design decisions and takeaways

Put the possible flow next to the path that actually ran

An editor describes possible paths; a run describes what happened. Linking them means people do not have to infer which branch a line of log output belongs to.

In the studio example, a missing notification need not mean the notification service is broken. An earlier condition may have routed the customer elsewhere. Seeing that path and then inspecting its data gives investigation an order. The memorable design move is grounding an abstract rule in one customer and one run.

Keep the process beside the result

An agent’s text only establishes that it produced an answer. Tool activity, material and usage let a reviewer ask what informed a customer summary, what it missed and which steps consumed resources. The block library also distinguishes an agent response from a stored attribute: a separate update action is required to save it.

That separation matters. “The answer was generated” and “the customer record was updated” are different outcomes. Generation, storage and business verification each have a place to be checked. A product can likewise show that a result exists separately from whether it has been applied, instead of hiding the gap behind one success message.

A new attempt preserves the earlier evidence

If rerunning after a correction overwrites the first failure, a team sees only today’s success and struggles to establish whether the change addressed the original problem. Attio keeps attempts under the same run so the failure and subsequent results can be compared.

The useful principle is continuity without overwriting: a new action belongs to the same problem, while retaining its own inputs and outcome. Users can then answer both why the first attempt failed and why they now believe the problem is resolved.