Track Champion Job Changes to Open New Accounts

Part 1: Before you start

1. 1.Install the Clay CLI

   Use version 1.3.1 or later, installed from Clay's own instructions. This page does not include an install command because the CLI reference it was written from does not list one. You also need jq, which the script uses to read the JSON the CLI prints.

2. 2.Log in to your workspace

   Browser login is the default. Use the device flow on a headless machine. A static key in the CLAY_API_KEY environment variable also works. Workflow commands need the terracotta:cli scope, so an auth error that names it means your login cannot manage workflows.

   Log in with a browser

   $ clay loginCopy

   Log in on a headless machine

   $ clay login --deviceCopy

   Confirm who you are logged in as

   $ clay whoamiCopy

3. 3.Pick the workspace to build in

   The workflow is created in your active workspace. Switch first if you belong to more than one.

   List workspaces

   $ clay workspaces listCopy

   Show the active workspace

   $ clay workspaces currentCopy

   Switch workspace

   $ clay workspaces switch <workspaceId>Copy

4. 4.Find your action keys

   Action package ids and keys are specific to your workspace. Save the catalog, search it for person enrichment from a LinkedIn URL, company enrichment, and Slack, then paste their ids into the top of the script. Skip "clay workflows actions test": it spends credits.

   Save the action catalog

   $ clay workflows actions list > catalog.jsonCopy

   Search the catalog

   $ grep -Eio '"[^"]*(enrich person|enrich company|linkedin|apollo|slack)[^"]*"' catalog.json | sort -uCopy

   See an action's inputs and outputs

   $ clay workflows actions schema <packageId> <actionKey>Copy

5. 5.Export your champions and connect Slack

   Export the primary contact from closed-won deals and active customers with the columns in the sample CSV, and connect Slack inside Clay.

6. 6.Optional: use a Clay job change signal instead

   If you already keep champions in a Clay table, the CLI can attach a JobChange signal to it. It creates a new destination table unless you pass one. Replace the ids with your table, view, and LinkedIn URL field.

   Create a job change signal on your champions table

   $ clay signals create --type JobChange --input '{"tableId":"t_...","viewId":"view_...","personIdentifier":{"fieldId":"f_...","pathAsFormula":"{{f_...}}"}}'Copy

Part 2: Workflow spec

What the script builds: Champion job change tracking.

1. 1

   Find current company and title

   action

   Re-enriches the person from their LinkedIn URL to get where they work now.

   Reads

   linkedin_url

   Writes

   current_companycurrent_domaincurrent_title
2. 2

   Check the new company

   action

   Enriches the new company so the alert shows whether it fits your ICP. Runs only when the domain changed.

   Reads

   current_domain

   Writes

   headcountindustrycountry

   Verify in your workspace: The "domain changed" rule needs a run condition, which the CLI help does not document. Set it in the Clay UI, or compare domains in a spreadsheet before uploading.
3. 3

   Alert the owner in Slack

   action

   Posts the move to the deal owner with the shared history, for example: "Jane Doe, who championed the Example Co annual plan, is now VP Sales at a 200-person fintech company."

   Reads

   first_namelast_namecurrent_titlecurrent_companyheadcountindustrydeal_ownerchampioned_deal

   Writes

   Slack message

Part 3: Build script

Creates the workflow, trigger, and three steps, then pauses so you can map step inputs and the domain-changed condition. It validates the graph, offers one test run, and asks before publishing.

Save it as build-champion-moves.sh, fill in the 6 action ids at the top, then run bash build-champion-moves.sh.

1#!/usr/bin/env bash2# Builds the "Champion job change tracking" Clay workflow3# in YOUR Clay workspace, using YOUR Clay CLI login.4# Written against Clay CLI v1.3.1. Not run or tested by GTM Playbooks.5# Lines tagged VERIFY use a shape the CLI help does not document.6set -euo pipefail7 8# Copy these from catalog.json (see "Find your action keys").9PERSON_PACKAGE_ID=""  # Person enrichment from a LinkedIn URL10PERSON_ACTION_KEY=""11COMPANY_PACKAGE_ID="" # Company enrichment (headcount, industry)12COMPANY_ACTION_KEY=""13SLACK_PACKAGE_ID=""   # Slack: send message14SLACK_ACTION_KEY=""15 16# One input to test before real traffic. Use yourself or a teammate.17TEST_ROW='{"first_name":"","last_name":"","linkedin_url":"","crm_company":"","crm_company_domain":"","deal_owner":"","championed_deal":""}'18 19for v in PERSON_PACKAGE_ID PERSON_ACTION_KEY COMPANY_PACKAGE_ID COMPANY_ACTION_KEY SLACK_PACKAGE_ID SLACK_ACTION_KEY; do20  [[ -n "${!v}" ]] || { echo "Set $v at the top of this script." >&2; exit 1; }21done22command -v clay > /dev/null || { echo "Clay CLI not found on PATH." >&2; exit 1; }23command -v jq > /dev/null || { echo "jq is required to read CLI output." >&2; exit 1; }24clay whoami > /dev/null || { echo "Not logged in. Run: clay login" >&2; exit 1; }25 26# VERIFY: only "workflows create" documents an "id" field in its output.27read_id() {28  local id29  id=$(jq -r '.id // empty' "$1")30  [[ -n "$id" ]] || { echo "No id found in $1. Open it and adjust read_id." >&2; exit 1; }31  echo "$id"32}33 34mkdir -p clay-champion-moves35cd clay-champion-moves36 37echo "1/7 Create the workflow"38clay workflows create --name "Champion job change tracking" > workflow.json39WF_ID=$(read_id workflow.json)40WF_URL=$(jq -r '.url // empty' workflow.json)41 42echo "2/7 Add the CSV upload trigger"43# VERIFY: triggerType "csv_upload" is inferred; the help does not show it.44clay workflows triggers create "$WF_ID" --input '{"triggerType":"csv_upload"}' > trigger.json45TRG_ID=$(read_id trigger.json)46 47echo "3/7 Step 1: find current company and title"48# VERIFY: help shows nodeType and name only; actionPackageId and actionKey are a guess.49STEP1=$(jq -nc --arg p "$PERSON_PACKAGE_ID" --arg k "$PERSON_ACTION_KEY" '{nodeType: "tool", name: "Find current company and title", actionPackageId: $p, actionKey: $k}')50clay workflows nodes create "$WF_ID" --input "$STEP1" > step1.json51STEP1_ID=$(read_id step1.json)52 53echo "4/7 Step 2: check the new company"54# VERIFY: action fields inside "step" are inferred from the documented utility example.55STEP2=$(jq -nc --arg n "$STEP1_ID" --arg p "$COMPANY_PACKAGE_ID" --arg k "$COMPANY_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}')56clay workflows nodes insert "$WF_ID" --input "$STEP2" > step2.json57STEP2_ID=$(read_id step2.json)58 59echo "5/7 Step 3: alert the owner in slack"60# VERIFY: same inferred insert shape as step 2.61STEP3=$(jq -nc --arg n "$STEP2_ID" --arg p "$SLACK_PACKAGE_ID" --arg k "$SLACK_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}')62clay workflows nodes insert "$WF_ID" --input "$STEP3" > step3.json63clay workflows graph get "$WF_ID" --mode full > graph.json64 65echo "6/7 Map step inputs"66cat <<EOF67 68Step inputs are specific to your workspace. Map them before validating:69  Step 1 person:  linkedin_url70  Step 2 company: the current domain from step 1; add a run condition so it71                  only runs when that domain differs from crm_company_domain72  Step 3 Slack:   name, new title and company, headcount, industry,73                  deal_owner, and championed_deal74Map them in the Clay UI${WF_URL:+ at $WF_URL}, or per node with:75  clay workflows nodes get $WF_ID <nodeId>76  clay workflows nodes update $WF_ID <nodeId> --input node.json77graph.json in this folder shows the current nodes and edges.78 79EOF80read -r -p "Press Enter when inputs are mapped. "81 82echo "7/7 Validate, test once, publish"83clay workflows graph validate "$WF_ID"84clay workflows diagram "$WF_ID"85 86if jq -e 'all(.[]; . != "")' <<< "$TEST_ROW" > /dev/null; then87  read -r -p "Run TEST_ROW once? It can spend Clay credits and post to Slack. [y/N] " answer88  if [[ "$answer" == [yY] ]]; then89    clay workflows runs test "$WF_ID" --inputs "$TEST_ROW" > test-run.json90    echo "Saved test-run.json. Check each step with: clay workflows runs steps $WF_ID <runId>"91  fi92else93  echo "TEST_ROW is empty, skipping the test run."94fi95 96read -r -p "Publish the workflow now? [y/N] " answer97if [[ "$answer" == [yY] ]]; then98  clay workflows publish "$WF_ID" --name v199fi100 101echo "Workflow $WF_ID, CSV upload trigger $TRG_ID. All responses are saved in $(pwd)."

Part 4: Champion CSV

Save this as clay-champion-moves/champions.csv and replace the sample row with your export. Keep the headers exactly as shown, because they become the trigger inputs.

1first_name,last_name,linkedin_url,crm_company,crm_company_domain,deal_owner,championed_deal2Jane,Doe,https://www.linkedin.com/in/your-test-profile,Example Co,example.com,owner@yourdomain.com,Example Co annual plan (2025)

Part 5: Run it on your champion list

After publishing, upload the CSV to the trigger and start with a few rows. Each row is one run.

Verify in your workspace

The Clay CLI help does not document these details. Check each one before you rely on the build.

• The CSV trigger type "csv_upload" is inferred. If "triggers create" exits with code 2 (validation), check which trigger types your workspace accepts.
• The help documents "nodes create" with nodeType and name only. If it rejects actionPackageId and actionKey, create the node with a name only and pick the action in the Clay UI.
• The reference says action steps take actionPackageId and actionKey but shows only a utility example for "nodes insert", so the placement of those fields inside "step" is inferred.
• Only "workflows create" documents an id field in its response. The script reads .id from trigger and node responses too and stops if it is missing.
• Package ids and action keys differ by workspace and depend on which integrations you have connected. Copy them from your catalog; this page does not guess them.
• Step input mapping is dynamic per workspace. The CLI path is "nodes get" then "nodes update", where incomingEdges is a full replacement. The argument order for "nodes get" is inferred from "nodes update".
• The help does not say whether step 1 connects to the trigger automatically. "clay workflows graph validate" reports a disconnected graph.
• The JobChange signal input shape comes from the CLI help example. The table, view, and field ids are yours to fill in.
• "runs test" without --live is assumed to run the draft. The reference lists --live without describing it.
• Workflow runs can spend Clay credits and write to connected tools. Exit code 3 means re-run clay login, and exit code 4 means you are rate limited (wait for details.retryAfter).