Skip to main content
When a deal reaches Closed won, this workflow summarizes it, creates an onboarding record and task, lists it, and pings Customer Success (CS) in Slack. The build starts with the Attribute value changed trigger. It fires when a deal’s Stage becomes Closed won. An If condition then guards against re-fires. This stops the same won deal from being handed off twice. Next it drafts a handoff brief with Summarize record. Finally it chains four actions: Create record, Create task, Add record to list, and a Slack message. The result is that no won deal slips through the gap between Sales and CS.

​
Prerequisites

  • A workspace on the Plus plan or higher.
  • The Slack integration connected, with a Customer Success channel such as #cs-onboarding.
  • A Deals object whose Stage status attribute includes a Closed won option.
  • An Onboarding object with three attributes: a Name, a Deal record-reference attribute pointing back to Deals, and an Owner. A record-reference attribute links one record to another. A CS list can stand in if you prefer not to model a separate object.
  • A list named Active onboarding that tracks in-flight handoffs.
No API key is needed. The Slack block posts through the connected integration, not a raw token.

​
How it works

The workflow watches one attribute on a deal. It acts only when that attribute settles on the right value. When Stage flips to Closed won, an If guard confirms the value actually changed. That way, re-saving an already-won deal does not replay the whole handoff. The run then summarizes the deal for CS, creates an onboarding record, and assigns the CS owner a task. It also files the deal on the active-onboarding list. Finally it announces the win in Slack with the summary inline. The blocks run in this order:
  1. Attribute value changed: fires when Deals, Stage changes to Closed won.
  2. If: checks that the old Stage value differs from the new one. This is the re-fire guard.
  3. Summarize record: drafts the deal brief for CS.
  4. Create record: creates the onboarding record.
  5. Create task: assigns a kickoff task to the CS owner.
  6. Add record to list: adds the deal to Active onboarding.
  7. Slack: posts the summary to the CS channel.

​
Build steps

1

Add the attribute-value-changed trigger

Create a new workflow and add the Attribute value changed trigger. Scope it to the Deals object and the Stage attribute. The workflow then wakes only when a deal’s stage moves.
2

Guard against re-fires with If

Add an If condition immediately after the trigger. Compare the old Stage value to the new one. A re-save or bulk edit of an already-won deal then cannot replay the handoff. Only the true branch continues.
3

Summarize the deal for CS

Add a Summarize record block on the true branch and point it at the deal from the trigger. Write a prompt aimed at the CS reader so the brief is actionable rather than a data dump. The Run as identity gives the block read-only access to the records the chosen user can already see.
4

Create the onboarding record

Add a Create record block targeting your Onboarding object. Link it back to the deal and seed the owner. CS then has a single home for the engagement.
5

Create a task for the CS owner

Add a Create task block so the handoff lands in someone’s queue, not just on a record.
6

Add the deal to the active-onboarding list

Add an Add record to list block so the deal appears on the CS board everyone watches.
7

Post the summary to Slack

Add a Slack block to announce the win and paste the brief inline. Reference the summary output with the variable shown. CS then reads the brief without opening Attio.

​
Variable mapping

​
Credit cost worked example

The fixed per-run costs come from four write blocks. The trigger is free. The If guard is also free, because a condition that stops a run consumes no credits. Create record, Create task, Add record to list, and the Slack message each cost 1 credit. So a completed handoff spends 4 write credits. The Summarize record block is variable and token-based. Its cost depends on how much deal context the model reads and writes, so a fixed number is misleading. To find your real cost, fire the workflow on roughly 10 representative deals. Read the actual per-run AI cost in the run viewer, then multiply by your volume. Take a realistic 40 closed-won deals per month. The writes cost 40 × 4 = 160 write credits per month, plus the AI cost (about 40 × your sampled per-summary figure). Check that combined total against your plan’s monthly allowance on Credits & pricing explained. Per-workflow credit caps were removed in the new engine, so the allowance lives at the plan level, not on this workflow.

​
Test plan

  1. Pick a sandbox deal still in Proposal. Open the run viewer in a second tab so you can watch each block.
  2. Move the deal’s Stage to Closed won. The Attribute value changed trigger should fire once.
  3. Confirm the If guard resolves true (old Proposal differs from new Closed won) and the run continues down the true branch.
  4. Confirm Summarize record returns a non-empty CS brief, and read its output in run history.
  5. Confirm a new Onboarding record exists and a task is assigned to the CS owner. Check that the deal appears on Active onboarding. Confirm the Slack message lands in #cs-onboarding with the summary text.
  6. Deliberately failing input: re-save the same already-won deal, setting Stage to Closed won again without a real change. The If guard should resolve false and stop the run. That produces no second onboarding record, task, list entry, or Slack message. Verify the stopped run in run history.

​
Failure modes

​
Variations

​
Skip the summary for small deals

Add a free Filter condition before Summarize record. Let it pass only deals above a threshold, such as annual contract value (ACV) of $25,000 or more. ACV is the yearly revenue a deal is worth. Small deals still get the record, task, list entry, and Slack ping. They simply skip the variable AI cost. Gating the AI block behind a free Filter keeps token spend on the deals that warrant a written brief.

​
Route by segment

Add a Switch condition after the guard, keyed on the deal’s Segment attribute (for example, EMEA, AMER, or SMB). Each branch sets a different owner, Slack channel, and list. The handoff then lands with the right team automatically.

​
See also

Source: Attio Help Center: Workflows overview. Last reviewed against the Attio Help Center, June 2026.