@dench.com/cli 3.11.6 → 3.11.7-staging.488
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/app-sdk.d.ts +6 -0
- package/campaign.ts +157 -43
- package/lib/api-schemas.ts +130 -57
- package/lib/campaign-agent.ts +136 -50
- package/lib/campaign-csv.ts +183 -53
- package/lib/enrichment-gateway.ts +9 -0
- package/lib/references.generated.json +4 -4
- package/package.json +1 -1
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
|
-
"revision": "
|
|
3
|
-
"builtinHash": "
|
|
2
|
+
"revision": "45561feb85b954d55b1a81a8ed27f461dc90ba8850ea340d90641856bba48235",
|
|
3
|
+
"builtinHash": "b390161ef1814ef80890e56b0f51f50dc6483769a76cf41de6b659393a4ceb7a",
|
|
4
4
|
"files": {
|
|
5
5
|
"SKILL.md": {
|
|
6
6
|
"sha256": "2995fdbc4644fc86239f3fa483c8f009d8639eceda2f74a48d6bc28d65a45a44",
|
|
@@ -27,8 +27,8 @@
|
|
|
27
27
|
"content": "---\nname: browser\ndescription: Use Dench Browser from sandbox Playwright scripts without provider credentials.\n---\n\n# Dench Browser Playwright CDP\n\nUse this reference when writing durable website automation scripts in a Dench\nsandbox.\n\nFor short interactive diagnosis, use the chat `browser` tool. For larger or\nrepeatable workflows, write a file-backed Playwright script in `/workspace` and\nconnect it to a Dench Browser CDP session.\n\n## Requirements\n\nThe sandbox already provides:\n\n- `DENCH_API_KEY` for the Dench gateway\n- `DENCH_GATEWAY_URL` for gateway routing\n- `DENCH_RUN_ID` so session metadata can attach to the chat run\n- `PLAYWRIGHT_CORE_PATH` so scripts can import Playwright without installing it\n\nYour persisted login profile is resolved server-side per signed-in user from the\nDench API key — there is no browser context id to pass and no\n`DENCH_BROWSER_CONTEXT_ID` env var. Do not look for browser provider API keys in\nthe sandbox.\n\n## Create A Session\n\n```bash\ndench browser session create --json\n```\n\nThe response includes:\n\n- `sessionId`\n- `connectUrl`\n- `liveViewUrl`\n- `status`\n- optional `contextId`\n\nThe CLI best-effort registers the session for the current `DENCH_RUN_ID`, so the\nchat Browser panel can show the live session and replay.\n\n## Connect With Playwright\n\n```js\nimport { pathToFileURL } from \"node:url\";\nimport { promisify } from \"node:util\";\nimport { execFile } from \"node:child_process\";\n\nconst execFileAsync = promisify(execFile);\n\nconst { chromium } = await import(\n pathToFileURL(process.env.PLAYWRIGHT_CORE_PATH).href\n);\n\nconst { stdout } = await execFileAsync(\"dench\", [\n \"browser\",\n \"session\",\n \"create\",\n \"--json\",\n]);\nconst session = JSON.parse(stdout);\nconst browser = await chromium.connectOverCDP(session.connectUrl);\nconst context = browser.contexts()[0];\nconst page = context.pages()[0] ?? (await context.newPage());\n```\n\nClose the Playwright connection when the script ends. Stop the Dench Browser\nsession unless the user needs to finish login in the live Browser panel:\n\n```bash\ndench browser session stop \"$SESSION_ID\" --json\n```\n\n## Repair Checklist\n\nIf a script cannot start:\n\n```bash\nnode -e 'console.log(JSON.stringify({ hasDenchApiKey: Boolean(process.env.DENCH_API_KEY), hasPlaywrightCorePath: Boolean(process.env.PLAYWRIGHT_CORE_PATH) }))'\n```\n\nIf a fresh session still looks logged out after the user completed login, the\nsaved profile catches up automatically on the next session — just create a new\nsession and retry.\n"
|
|
28
28
|
},
|
|
29
29
|
"references/CAMPAIGNS.md": {
|
|
30
|
-
"sha256": "
|
|
31
|
-
"content": "---\nname: campaigns\ndescription: \"Build, run and fix email + LinkedIn outreach campaigns with `dench campaign` (CLI/API), starting from a raw brief: ask the setup questions with recommended answers from organization memory, then build from any of the five sources (buying signals, lookalike of a best lead, pasted leads or CSV, CRM records, a people search), write steps and personalized lines, set senders, schedule and approval, check launch readiness, launch, run signals now, approve new people, then track replies, the funnel and hold reasons. Use for any request to set up, edit, duplicate, delete or monitor an outreach, cold-email or LinkedIn campaign or sequence.\"\n---\n\n# Dench Outreach Campaigns\n\nAn **outreach campaign** sends a sequence of steps — emails from a connected\nGmail/Outlook mailbox, LinkedIn profile visits, connection requests and\nmessages from a connected LinkedIn account — to a list of people, one person\nat a time, inside a send window. The steps run in order, or as a workflow\nwhose If / else and Wait for them to accept steps send people down different\npaths. It is the Outreach → Campaigns page in the\nDench app, and everything that page does is also a `dench campaign …` command\nor an API call. Every command takes `--json`. Notices and cost lines go to\nstderr and stdout is plain JSON, so `> file.json` is safe.\n\n`draft`, `create`, `duplicate` and `get` include named `references`, a canonical\n`href`, and an absolute `url` when the connected workspace slug is available.\nLink the campaign name using that result rather than displaying its raw ID or\nmaking an extra lookup to construct a URL. `list --with-references --json` wraps\nthe ordinary list in `{data, references, referenceCoverage}`; plain `list --json`\nstill returns the original array. The reference identity is the Outreach\n`sequenceId`, never the separate CRM campaign mirror's entry ID.\n\nCampaign analytics scans the full history in bounded server-side pages. The\nJSON result includes `startedAt` and `computedAt`: totals reflect that\nobservation interval, not an atomic snapshot while sending continues. The\ndashboard refreshes every minute.\n\nNot this skill: one-shot newsletters and raw `dench email send` live in\n`email-campaigns`. Prospecting on its own (no campaign) is `sales` / `dench\nleads find`. A CRM record's history is `crm`.\n\n## Ask first, with recommended answers\n\nBefore building anything, settle the campaign with the user in ONE message of\nshort numbered questions. Every question carries a **recommended answer** the\nuser can accept with \"yes\" or a number. Never send a question without one,\nand never ask what the brief already answers. Say what you inferred instead.\n\n**Where the recommendations come from**, in this order:\n\n1. **Organization memory**: the `## Organisation` section of your system\n prompt, or `read_file /ORGANISATION.md`. It says what the company sells,\n to whom, the market, competitors and voice.\n2. **`dench campaign builder profile --json`** (free). It returns the\n workspace's saved ICP (`targeting`), suggested targeting, `defaultSignals`,\n suggested terms per signal (`suggestions`), and whether a LinkedIn account\n and a mailbox are connected (`hasLinkedin`, `hasMailbox`).\n3. **`dench campaign accounts --json`** for the sender ids.\n\nIf organization memory says nothing about what the company sells or who it\nsells to, ask that first: \"What do you sell, and who buys it?\" Offer to save\nthe answer with `update_organisation`, then derive the rest from it.\nRecommendations must come from these sources. Never fill them with generic\nB2B defaults.\n\n**The questions** (skip any the brief settles; keep each to one line plus the\nrecommendation):\n\n| # | Ask | Recommend |\n|---|---|---|\n| 1 | **Where people come from**: Signals (people showing buying intent), Lookalike (people like your best lead), Existing leads (paste or CSV), From CRM, or Find new people (a filtered search) | Signals when organization memory describes a problem people post or hire for; Lookalike when the user names a best customer; From CRM when they mean people they already know |\n| 2 | **Who**: titles, industries, company sizes, locations, who to leave out | The ICP from organization memory and `builder profile`. Name competitors from memory as exclusions |\n| 3 | **Which signals and terms** (signals only) | `defaultSignals`, plus 2-4 topics from `suggestions` rewritten as **what the buyer does**, e.g. \"using AI for outbound\" rather than \"Claude\" (see Topics below) |\n| 4 | **Channels and goal**: email, LinkedIn or both; what a reply should lead to; tone | Both when `hasLinkedin` and `hasMailbox`, else the connected one; the goal and tone from organization memory |\n| 5 | **Who sends and when**: mailboxes and LinkedIn accounts, days, hours, timezone, daily email cap | Every connected account, Mon-Fri 9-17 in the user's timezone, 30 emails a day |\n| 6 | **Approval** (signals and lookalike): new people start on their own, or wait for approval | Manual review (the app's default) for a new campaign; automatic once the first week's people look right |\n| 7 | **How often signals run** and whether to add matching people without a signal | Daily; add matching people off |\n\nAfter the answers, restate the plan in five lines (source, who, signals,\nchannels and senders, approval) and say what will cost money before any\nbillable step.\n\n## Build a campaign from a brief\n\nThe brief can be an ICP document, a list of titles and companies, a sequence\nexported from another outreach tool, or one sentence. Follow these steps in\norder. Only step 3 (search), step 6 (AI lines) and step 9 (launch) spend money\nor send messages; say so before each one and wait for a yes before step 9.\n\n### 0. Check the prerequisites\n\n- **Campaign commands available.** Run `dench campaign help` and confirm it\n lists `draft`, `search`, `add`, `steps`, `person` and `preview`. An older CLI\n answers \"Unknown campaign subcommand: search\". Update with `npm install -g @dench.com/cli@latest`,\n or run commands as `npx -y -p @dench.com/cli@latest dench …`. The CLI comes\n preinstalled in a Dench chat sandbox. When testing a source checkout, check\n its campaign help: commands can be available before a release version bump.\n- **A workspace member's credentials.** `dench signin` (the human approves a\n link), a member-bound `DENCH_API_KEY`, or an agent session a member created.\n An organization-only key is refused with \"Outreach needs a workspace\n member's credentials\". Check with `dench context --json`.\n- **A paid workspace with credits.** Search and AI lines are billed to the\n workspace. `dench billing status --json` shows the balance; `dench upgrade`\n and `dench billing topup --amount 10` give the human a link.\n- **Connected senders.** `dench campaign accounts --json` must list a mailbox\n (for email steps) and/or a LinkedIn account (for LinkedIn steps). If a\n channel is empty, `dench tool connect gmail` (or `outlook`, `linkedin`)\n prints a sign-in link; the human opens it, then run `dench campaign\n accounts` again. Ids from this command go into `--email-mailboxes` and\n `--linkedin-accounts`.\n\n### 1. Turn the brief into a plan\n\nPull these out of the brief and ask the user only for what is missing:\n\n| Need | Where it goes |\n|---|---|\n| Who to reach: titles, seniority, industries, company size, places | search filters (step 3) |\n| Who to leave out: competitors, dev shops, current clients, wrong industries | exclusions (step 3) |\n| How many people | one campaign holds at most 300 (step 4) |\n| Channels and timing: which touches, how many days apart | `steps.json` (step 7) |\n| Branches: \"if they're connected…\", \"if they don't accept…\", \"if their title contains…\" | a workflow `steps.json` (step 7) |\n| What changes per person: first name, company, a role or reason to write | variables (steps 5 and 6) |\n| Timezone, days and hours, daily email cap, which accounts send | the draft (step 2) |\n| Buying signals (hiring, funding, launches, new leaders, post engagement) | the signal builder, below, instead of steps 3 and 4 |\n\nFilter names, exact values and ranges: `dench leads filters` (free) lists\nthem, `dench leads filters --filter industries --search \"financial\"` finds an\nexact industry name. Company size is a headcount bucket (`1-10`, `11-50`,\n`51-200`, `201-500`, `501-1000`, `1001-5000`, `5001-10000`, `10001+`); there is\nno revenue filter.\n\n### 2. Create the draft\n\n```bash\ndench campaign draft --name \"Fintech engineering leaders\" \\\n --request-id fintech-eng-leaders-q4 --timezone America/New_York \\\n --window \"Mon-Fri 9-17\" --daily-cap 30 \\\n --email-mailboxes <mailboxId> --linkedin-accounts <linkedinAccountId> --json\n```\n\n`--request-id` (8-64 characters) makes a retry return the same draft instead of\na second one. Without sender flags the draft sends from every running account\nyou own; the output says which. A draft sends nothing.\n\n### 3. Search, with exclusions\n\n```bash\ncat > filters.json <<'EOF'\n{\n \"titles\": [\"CTO\", \"VP Engineering\", \"Head of Engineering\"],\n \"industries\": [\"Financial Services\", \"Hospitals and Health Care\"],\n \"headcountRanges\": [\"51-200\", \"201-500\", \"501-1000\"],\n \"locations\": [\"United States\"]\n}\nEOF\n\ndench campaign search --filters @filters.json \\\n --not-industries \"IT Services and IT Consulting,Staffing and Recruiting\" \\\n --not-company-keywords \"software outsourcing\" \\\n --not-domains competitor.com,current-client.com \\\n --limit 25 --out audience.json\n```\n\n- **Cost: 1 cent per person returned**, billed on what comes back, not on the\n limit. The most a call can cost prints on stderr before it runs, and the\n result carries `estimatedCents` and `chargedCents`. There is no free preview;\n start with `--limit 25`, read the sample, then widen.\n- **Exclusions.** `--not-<filter>` (or `--exclude-<filter>`) works on every list\n filter, for example `--not-industries`, `--not-titles`, `--not-company-names`,\n `--not-company-keywords`; `--not-domains` is short for `--not-company-domains`.\n In JSON an exclusion is `{\"value\":\"Staffing and Recruiting\",\"exclude\":true}`\n inside that filter's list. A search still needs at least one include filter.\n- `--limit` is at most 100 per search. Continue with `--page-token\n <nextPageToken>` from the previous result (even after an empty page); keep the\n same filters.\n- `--out audience.json` writes the full result, complete profiles included, and\n the terminal shows a short summary. `--raw` prints the full result instead of\n writing a file. The file is checked before the search is billed: its folder\n must exist and the file must not (`--force` replaces it), so give each page\n its own name (`audience-2.json`). If the write still fails, the result prints\n on stdout with a `saveError` instead of being lost; do not run the search\n again.\n- Review before adding: `jq -r '.rows[] | [.name,.title,.company] | @tsv'\n audience.json`. Show the user 5-10 people and the cost so far. If the sample is\n wrong, change the filters and search again (each search is billed).\n\n### 4. Add the people\n\n```bash\ndench campaign add \"Fintech engineering leaders\" --people-file audience.json\n```\n\nThis adds the searched people without searching or paying again, up to 300\npeople per file, in batches of 50. New people become Leads in the CRM. The\nresult lists `added`, `duplicates`, `duplicatesElsewhere` (already queued or\nenrolled in another campaign, skipped unless `--allow-duplicates`), `suppressed`,\n`invalid`, `skippedNoIdentity`, `skippedMissingInfo` and `cappedAtLimit`. Read\nit back to the user.\n\nOther ways in, all with the same checks: `add --search '<filters json>'\n--limit 50` (search and add one page in a single billed call), `add --csv\npeople.csv`, `add --list <artifactId>`, `add --object lead --view \"<view>\"`,\n`add --name \"Ada\" --email ada@x.com`. See Add people below.\n\n- **A campaign holds 300 people**, counting stopped and finished ones. For a\n bigger audience, `dench campaign duplicate <campaign>` makes a new draft with\n the same steps, schedule, senders and lines and no people; add the next page\n of the search to the copy (`search --page-token …`). Duplicate checks include\n draft, active and paused campaigns, so someone queued or enrolled elsewhere\n is skipped.\n- People need an email for email steps and a LinkedIn profile URL for LinkedIn\n steps. A person without an email has their email steps skipped (launch warns);\n someone with neither is a launch blocker. Search results carry a LinkedIn URL\n and, when available, an email.\n- A mistake in a draft: `dench campaign remove <campaign> --person\n <enrollmentId|name>` takes a never-contacted person out and frees their place.\n\n### 5. Choose the variables\n\nA `{{token}}` or `[[token]]` in a subject or message is filled in per person.\nBoth forms work in email and LinkedIn messages, InMail subjects, previews and\nsends. Typing either opener brings up field suggestions, and choosing a field\nkeeps the brackets you started with:\n\n- **Fields of the person or their CRM row:** `{{First name}}`, `{{Company}}`,\n `{{Job Title}}`, `{{Website}}`, `{{Location}}` and any other column of the\n record.\n- **Values you supply.** In a `--people-file`, put them under `personalization`\n for each person: `{\"linkedinProfileUrl\":\"…\",\"personalization\":{\"fund\":\"Seed\n fund\",\"role_title\":\"Head of Data\"}}` makes `{{fund}}` and `{{role_title}}`. In\n a CSV every column that is not an email, LinkedIn URL or name becomes a value\n named after its header.\n- **Greeting names.** Built-in `name`, `firstName` and `lastName` are cleaned\n for greetings, so casing and credentials may change. Custom keys such as\n `first_name`, `Fund` and `role_title` keep the values you supply. To confirm\n an exact built-in name, use `dench campaign person set <campaign> --person\n <name> --field \"name=Hortensia Ruiz, MBA\"`.\n- **Fallbacks.** `{{First name || \"there\"}}` or `[[First name || \"there\"]]`.\n A plain token with no value for\n someone is a **launch blocker** for that person; a quoted fallback avoids it.\n Fix a single person before launch with `dench campaign person set\n <campaign> --person <name> --field \"Company=Acme\"`, or pull missing fields\n from their CRM record with `dench campaign sync <campaign>`.\n- **Brackets.** Write `{{First name}}` or `[[First name]]`, with a matching\n pair of double braces or square brackets. `steps set` refuses\n `{first_name}` or `{FIRST_NAME}`, which would go out exactly as typed; pass\n `--allow-single-braces` only when the braces are literal text.\n\n### 6. Optional: AI-written lines\n\nFor a line that must differ for every person (a reason to write, a comment on\ntheir company), define up to 5 AI-written lines. They cost about 3 cents a\nperson; say so, then:\n\n```bash\ncat > lines.json <<'EOF'\n{\n \"sells\": \"Senior engineers who join your team or own a build end to end\",\n \"lines\": [\n {\n \"label\": \"Why now\",\n \"instructions\": \"One sentence tying their company's business to engineering capacity.\",\n \"fallback\": \"building the roadmap faster\"\n }\n ]\n}\nEOF\ndench campaign personalize set \"Fintech engineering leaders\" --file lines.json\ndench campaign personalize get \"Fintech engineering leaders\"\n```\n\nUse the line in steps as `{{whyNow}}` (the key is made from the label; `get`\nprints it). Saving writes lines for up to 100 people right away; more waits\nfor `personalize write --yes`. Edit one person's line with `personalize edit`,\nredo it with `personalize rewrite`. Until a line is written the saved fallback\nis used and it never blocks launch.\n\n### 7. Write and check the steps\n\nFirst decide the shape. If everyone gets the same touches in the same order,\n`steps.json` is a plain JSON array in send order. If the brief says \"if …,\nthen …\" (connected or not, accepted or not, has an email or not, a field's\nvalue), it is a workflow: `{\"stepModel\":\"workflow\",\"steps\":[...]}` with\npaths (see Workflows below). Each step is one of `email`, `wait`,\n`linkedin_visit`, `linkedin_connection`, `linkedin_message`,\n`linkedin_like_post` or `linkedin_inmail`; a workflow can also use\n`condition` (If / else) and `wait_for_connection` (Wait for them to accept).\nTiming is a `wait` step between the\ntouches: wait hours = (day of this touch − day of the\nprevious touch) × 24. This example turns \"email day 1, LinkedIn connect day 2,\nLinkedIn message day 4 after they accept, email day 5 in the same thread,\nLinkedIn bump day 8, email day 10 in the same thread\" into steps:\n\n```json\n[\n {\n \"type\": \"email\",\n \"emailSubject\": \"Keep building while you hire\",\n \"emailTextBody\": \"{{First name || \\\"Hi\\\"}}, saw {{Company}} is hiring for {{role_title || \\\"engineering\\\"}}. We add senior engineers to your team or own a build end to end.\\n\\nWant me to send a few profiles?\"\n },\n { \"type\": \"wait\", \"waitHours\": 24 },\n {\n \"type\": \"linkedin_connection\",\n \"linkedinMessageBody\": \"{{First name || \\\"Hi\\\"}}, saw {{Company}} is hiring. We add senior engineers to your team on your hours. Open to connecting?\"\n },\n { \"type\": \"wait\", \"waitHours\": 48 },\n {\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Thanks for connecting, {{First name || \\\"there\\\"}}. Want me to send a few profiles that match your open roles?\",\n \"linkedinMessageMode\": \"wait_until_connected\",\n \"connectionTimeoutHours\": 336\n },\n { \"type\": \"wait\", \"waitHours\": 24 },\n {\n \"type\": \"email\",\n \"emailReplyToPrevious\": true,\n \"emailTextBody\": \"Following up on the {{role_title || \\\"engineering\\\"}} role. Can we find 15 minutes this week?\"\n },\n { \"type\": \"wait\", \"waitHours\": 72 },\n {\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Circling back, {{First name || \\\"there\\\"}}: worth 15 minutes this week?\",\n \"linkedinMessageMode\": \"skip_if_not_connected\"\n },\n { \"type\": \"wait\", \"waitHours\": 48 },\n {\n \"type\": \"email\",\n \"emailReplyToPrevious\": true,\n \"emailTextBody\": \"Last note from me. Want me to send a few profiles?\"\n }\n]\n```\n\n```bash\ndench campaign steps set \"Fintech engineering leaders\" --file steps.json\ndench campaign preview \"Fintech engineering leaders\" --person \"Ada Lovelace\"\n```\n\n`steps set` validates before it saves and refuses anything that would be\nsilently dropped or sent wrong (rules in Steps below). `preview` shows the exact\nmessages one person would get, with every token and AI line filled in, and\nsays what is missing or would be skipped; nothing is sent. Preview two or\nthree different people and show the user the text. In a workflow, `preview`\nshows the message of every path, and a person gets only the ones on the path\nthey take: say which path each message is on, or preview one with `--step N`.\n\nPost reactions, InMail and scheduled withdrawal of pending invitations are\nsupported; see the Steps section for their fields and limits. A plain list\nlike the one above runs every step in order for everyone; `onlyIf` on email\nand post-like steps and `linkedinMessageMode` adjust it to whether someone\nis connected. When the brief branches (\"if they are connected, message them;\nif not, send a connection request, wait 10 days for the accept and InMail the\nones who don't accept\"), write a workflow instead (Workflows under Steps):\neach step gets a `key` and says where it goes, and If / else (`condition`)\nand Wait for them to accept (`wait_for_connection`) steps choose the path.\nBefore saving, tell the user how you mapped the brief: each \"if\" and the\nstep that answers it, where the paths join again, where each one ends, and\nanything you changed because a workflow can't do it (a path that goes back\nto an earlier step, more than 20 steps). Dench also checks whether someone\nis already connected before sending an invitation.\n\n### 8. Check readiness\n\n```bash\ndench campaign launch \"Fintech engineering leaders\" --check --json\n```\n\n`--check` never launches. It lists each blocker with why it fires and the\ncommands that fix it, the warnings, the audience and step counts and the\n`fingerprint`, and exits 1 when blocked. Fix blockers (`steps set`, `add`,\n`remove`, `person set`, `set`) and run it again until it exits 0.\n\nThen show the user, in one message: the number of people and five examples, the\nsteps as rendered by `preview`, the schedule and timezone, the daily email cap,\nthe sending accounts, what has been spent, and that LinkedIn steps break\nLinkedIn's terms and can get the account restricted. Ask for a clear yes.\n\n### 9. Launch and watch\n\n```bash\ndench campaign launch \"Fintech engineering leaders\" --ack-linkedin-risk\ndench campaign get \"Fintech engineering leaders\"\ndench campaign replies \"Fintech engineering leaders\" --since 7d\n```\n\n`--ack-linkedin-risk` is required only when the campaign has LinkedIn steps and\nonly after the user accepts the notice. `launch` without `--check` launches as\nsoon as the campaign is ready. After launch:\n\n- `get` is the dashboard: funnel, what is sending now, what comes next and\n why anything is holding (hold reasons clear on their own; report the hold,\n not a failure). `events` is the activity log; `people --status replied` lists\n who answered; `replies` shows what they wrote; `pipeline` shows where people\n sit in the lead pipeline.\n- Change wording or waits in place with `steps edit`; stop a person with `stop`;\n `pause` and `resume` the whole campaign.\n- Replying to a prospect happens in the Inbox in the Dench app.\n\n### Fixing mistakes\n\n| Mistake | Fix |\n|---|---|\n| Added the wrong person (draft) | `dench campaign remove <c> --person <id>` |\n| Wrong email or LinkedIn URL (draft) | `dench campaign person set <c> --person <id> --email … --linkedin-url …` |\n| Typo in a message after launch | `dench campaign steps edit <c> --file steps.json` |\n| Step types, order or a workflow's paths must change after launch | `steps edit` keeps them fixed. `dench campaign duplicate <c>`, fix the copy, and add only people who were never contacted to it |\n| Person should stop getting messages | `dench campaign stop <c> --person <id>` |\n| Whole campaign is wrong | `dench campaign pause <c>`, or `archive` / `delete` (same thing: stops everyone, erases nothing) |\n| A search was too broad | Nothing refunds a search; narrow the filters, and check `estimatedCents` first |\n\n## The New campaign flow (all five sources)\n\nThe app's **New campaign** page starts by asking where people come from. Each\nanswer to question 1 maps to commands:\n\n| Source | What it is | Commands |\n|---|---|---|\n| **Signals** | People showing buying intent, found again on a schedule | `builder save` (`\"source\":\"signals\"`) → `build` → `get` → `sequence`/`outreach` → `create` |\n| **Lookalike** | People like one best lead, found again on a schedule | `builder lookalike` → `save` (`\"source\":\"lookalike\"`, `\"signals\":[\"lookalike\"]`, `lookalike`) → the same as Signals |\n| **Existing leads** | A pasted list or a CSV | `draft` → `add --csv` / `--people-file` / `--name … --email …` (steps 2 and 4 above) |\n| **From CRM** | Records already in the CRM | `draft` → `add --object lead --view \"<view>\"` or `--entries` (Add people below) |\n| **Find new people** | A one-time filtered search | `draft` → `search` → `add --people-file` (steps 2-4 above) |\n\nSignals and Lookalike keep finding people after launch. The other three are a\nfixed list.\n\n### Signals and Lookalike, step by step\n\n```bash\ndench campaign builder profile --json # recommendations (free)\ndench campaign builder autofill --description \"VP Sales at US SaaS companies\" --json # optional: words -> targeting\ndench campaign builder estimate --data '{\"kind\":\"week\",\"targeting\":{...},\"signals\":[\"post_engagement\"],\"signalTerms\":{...}}' --json\ndench campaign builder save --file draft.json --json # -> draftId; nothing billed yet\ndench campaign builder build <draftId> --json # billable: finds the first people, writes openers\ndench campaign builder get <draftId> --json # poll until status is ready; review people and openers\ndench campaign builder opener <draftId> <leadId> --text \"...\" --json # fix an opener (\"\" resets it)\ndench campaign builder sequence <draftId> --goal \"Book a demo\" --help-with \"...\" --tone conversational --channels both --json\ndench campaign builder outreach <draftId> --file outreach.json --approval manual --json\ndench campaign builder create <draftId> --name \"...\" [--paused] --json # makes the campaign; does not launch\n```\n\nThen check readiness and launch as in steps 8 and 9 above. `create --paused`\nis the app's \"Save paused\": signals wait to run until launch.\n\n**`draft.json`** (every field the app saves):\n\n```json\n{\n \"clientRequestId\": \"ai-sales-leaders-2026-10\",\n \"name\": \"AI-curious sales leaders\",\n \"source\": \"signals\",\n \"targeting\": {\n \"titles\": [\"VP Sales\", \"Head of Sales\", \"CRO\"],\n \"industries\": [\"Software Development\"],\n \"companySizes\": [\"51-200\", \"201-500\"],\n \"locations\": [\"United States\"],\n \"excludes\": [\"competitor.com\"],\n \"companyTypes\": [\"Startup\"]\n },\n \"signals\": [\"post_engagement\", \"hiring\", \"funding\"],\n \"signalTerms\": {\n \"post_engagement\": [\"using AI for outbound\", \"AI SDR results\"],\n \"hiring\": [\"SDR\", \"Sales Development Representative\"]\n },\n \"findMoreMatching\": false\n}\n```\n\n- **Signals**: `post_engagement` (people who post or comment on a topic),\n `keyword` (posts mentioning a keyword), `hiring` (companies hiring a role),\n `funding`, `launch`, `new_leader`, `voice_engagement` (people engaging with\n chosen LinkedIn experts; terms are profile URLs, suggested by `builder voices\n --topics \"...\"`), `company_engagement` (people engaging with a company's or a\n competitor's page; terms are company page URLs), `brand_engagement` (people\n engaging with your own company page), and `lookalike` (Lookalike source\n only).\n- **Topics** (`post_engagement`, `keyword`): write what the buyer does or\n wants, not a bare product or brand name. Dench reads each topic for its\n meaning and searches for posts about that meaning, so \"Claude for GTM\" means\n sales teams using AI for sales, never posts that only mention Claude. A topic\n in `\"exact\": [\"keyword\"]` is searched as typed and the post must contain it.\n- **`findMoreMatching: true`** also adds people who match the audience without\n a signal.\n- **Lookalike**: `builder lookalike --linkedin-url <url>` returns the seed and\n an editable setup (role, `similarRoles`, `roles`, location, industry,\n `relatedIndustries`, `industries`, `companySizes`, similar `companies`).\n Show it to the user, apply their edits, and pass it as `lookalike` in\n `draft.json`. `--data '{\"suggest\":{\"title\":\"…\"}}'` suggests roles again;\n `--data '{\"rescope\":{\"seed\":{…},\"company\":\"…\"}}'` switches the company.\n\n**`outreach.json`** (the app's Outreach and Review screens):\n\n```json\n{\n \"brief\": {\"goal\": \"Book a demo\", \"helpWith\": \"...\", \"tone\": \"conversational\", \"channels\": \"both\"},\n \"steps\": [{\"type\": \"linkedin_connection\"}, {\"type\": \"wait\", \"waitHours\": 48}, {\"type\": \"email\", \"emailSubject\": \"...\", \"emailTextBody\": \"...\"}],\n \"sending\": {\"emailMailboxAccountIds\": [\"...\"], \"linkedinAccountIds\": [\"...\"], \"timezone\": \"America/New_York\",\n \"startHour\": 9, \"endHour\": 17, \"weekdays\": [1,2,3,4,5], \"dailySendCap\": 30},\n \"approvalMode\": \"manual\"\n}\n```\n\n`builder sequence` writes `steps` from the brief, as **Generate sequence**\ndoes (AI credits apply). Leave `steps` out of `outreach.json` after it, or use\n`--mode manual` with your own steps. In `weekdays`, 0 is Sunday.\n`approvalMode` `manual` (the default) holds each new person a signal finds\nuntil someone approves them. `auto` starts them on their own.\n\n**Drafts**: every save is resumable. `builder drafts` lists unfinished ones,\n`builder resume <draftId>` shows a draft's setup, `builder discard <draftId>`\ndrops it. `save` with the same `clientRequestId` updates the same draft.\n\n### A live signal campaign (the Sources tab)\n\n```bash\ndench campaign sources overview \"<campaign>\" --json # each signal: status, last/next run, people found, problems\ndench campaign sources run \"<campaign>\" --json # Run now (billable; 6 an hour; live campaigns only)\ndench campaign sources pending \"<campaign>\" --json # people waiting for approval\ndench campaign sources approve \"<campaign>\" --people <enrollmentId,...>\ndench campaign sources reject \"<campaign>\" --people <enrollmentId,...>\ndench campaign sources set \"<campaign>\" --approval auto\ndench campaign sources set \"<campaign>\" --data '{\"cadence\":\"weekly\"}'\ndench campaign sources set \"<campaign>\" --data '{\"signal\":{\"signal\":\"hiring\",\"enabled\":false}}'\ndench campaign sources set \"<campaign>\" --data '{\"terms\":{\"signal\":\"post_engagement\",\"values\":[\"using AI for outbound\"]}}'\ndench campaign sources preview \"<campaign>\" --signal hiring --json # sample results; enrolls no one\ndench campaign queue \"<campaign>\" --json # who goes out today, warmest first\n```\n\n- Each run continues where the last one stopped and skips people already in\n the campaign, so a quiet day means nothing new was posted, not a broken\n signal. `Run now` is for testing a change right away.\n- `sources set` takes one change per call: `status` (`active`/`paused`),\n `cadence` (`daily`/`weekly`/`monthly`), `findMoreMatching`, `approvalMode`,\n `targeting`, one `signal` on or off, or one signal's `terms`.\n- **Intent** (the bars next to each person on the Leads tab): High, Medium\n or Low. It weighs fit with the campaign's target titles and\n buyer profile first, then the signal. Someone outside the target titles is\n Low however strong their post. Warmer people go first in today's queue.\n Someone whose title is a different job altogether (HR commenting on a\n sales post; not just another word or level for a target title) is Low\n whatever they posted, and a signal lead like that is removed before\n anything is sent; the source won't add them again. Changing the target titles\n re-rates everyone in the campaign.\n\n## Commands\n\n`<campaign>` is a campaign **id or its exact name** (case-insensitive). When\ntwo live campaigns share a name the command fails and lists both ids; use the\nid. `dench campaign list` shows ids.\n\n### Browse and inspect\n\n```bash\ndench campaign list [--all] [--json] # live campaigns; --all includes archived\ndench campaign get <campaign> [--json] # status, schedule, funnel, Now/Next, holds, people\ndench campaign people <campaign> [--status <s>] [--json]\ndench campaign events <campaign> [--limit 50] [--max-pages 1] [--json]\ndench campaign accounts [--json] # email + LinkedIn sender ids, warm-up, availability and capacity\ndench campaign preview <campaign> [--person <enrollmentId|name>] [--step N] [--json]\ndench campaign person show <campaign> --person <enrollmentId|name> [--json]\ndench campaign replies <campaign> [--person <enrollmentId|name>] [--since 7d] [--limit 20] [--json]\ndench campaign pipeline <campaign> [--json]\ndench campaign where <entryId> [--json]\n```\n\n`people --status` accepts an enrollment status: `draft` (not launched yet),\n`active`, `paused`, `finished` (reached the end: every step of a plain list, or\nthe end of their path in a workflow), `replied`, `stopped`,\n`bounced`, `complained`, `unsubscribed`, `failed`.\n\n`events` is the campaign's activity log, newest first: added, launched,\nemail sent, connection request sent, accepted the connection, LinkedIn\nmessage sent, profile visited, replied, step skipped, step failed, needs a\nlook, paused, resumed, stopped, finished, bounced, unsubscribed, campaign\ncompleted, campaign picked back up, campaign archived. `--limit` is the page size (1-200);\n`--max-pages` drains more pages. `--json` returns `{ events, isDone,\ncontinueCursor }`.\n\n`preview` renders every email and LinkedIn step (or step N) for one person\n(the first person when `--person` is left out) with fields and AI lines filled\nin. In a workflow that is every path's messages; the person gets only the ones\non their path. `person show` lists each step a person reached with its outcome (sent,\nopened, clicked, skipped and why, waiting, failed), when, and the subject and\nstart of the text that was sent. `replies` lists the people who replied, newest\nfirst, with the text of their latest inbound email or LinkedIn message (up to\n400 characters, quoted history removed) and whether you have answered.\n`pipeline` counts a campaign's people at each lead Status. `where <entryId>`\nlists the campaigns a CRM person or lead is in and their status in each.\n\n### Create and configure\n\n```bash\ndench campaign create --name \"<name>\" [--timezone <IANA tz>] \\\n [--window \"<spec>\" ...] [--daily-cap 1-100] [--stop-on-reply|--no-stop-on-reply] \\\n [--email-mailboxes id1,id2] [--linkedin-accounts id1,id2] \\\n [--start <ISO date/time>] [--end <ISO date/time>] [--json]\n\ndench campaign draft [--name \"<name>\"] [--request-id <8-64 chars>] [same settings as create] [--json]\n\ndench campaign set <campaign> [--name \"<new name>\"] [--timezone <tz>] [--window \"<spec>\" ...] \\\n [--daily-cap 1-100] [--stop-on-reply|--no-stop-on-reply] \\\n [--email-mailboxes id1,id2|none] [--linkedin-accounts id1,id2|none] \\\n [--start <ISO>|--clear-start] [--end <ISO>|--clear-end] [--json]\n\ndench campaign duplicate <campaign> [--name \"<name>\"] [--json]\ndench campaign archive <campaign> [--json] # stops everyone still in flight; final\ndench campaign delete <campaign> [--json] # the same command, named like Delete in the app\n```\n\n`create` and `draft` make the same kind of draft; `draft` is the retry-safe\none (a stable `--request-id`) and the name is optional.\n\n- `--timezone` defaults to the machine's timezone (UTC in a sandbox — pass\n the user's zone). With no `--window`, the campaign gets one window:\n Mon-Fri 9-18 in that timezone.\n- `--daily-cap` is the number of cold emails per day across the campaign\n (default 30, max 100). LinkedIn has its own per-account limits, set on the\n account, not here.\n- `--email-mailboxes` and `--linkedin-accounts` select **sender pools on the\n campaign**, not on individual steps. Each accepts up to 50 account ids,\n comma-separated or as a JSON array. Only accounts both the caller and the\n campaign owner may use are accepted. The app puts these under **Settings →\n Sender pools**, with remaining-today counts and availability.\n- Omit a sender flag to preserve that channel's current configuration. Pass\n `none` or `'[]'` to clear it. Legacy per-step senders remain until that\n channel's pool is explicitly configured. Each person's assigned sender\n stays fixed through their conversation, including after a pool is changed;\n disconnecting it does not silently move the conversation to another sender.\n- API equivalents: `emailMailboxAccountIds` and `linkedinAccountIds` on\n `POST /campaigns` and `PATCH /campaigns/{sequenceId}`. Launch readiness\n checks remain mandatory; selecting a sender does not bypass them.\n- `--stop-on-reply` (the default) stops a person's remaining steps the\n moment they reply on either channel. `--no-stop-on-reply` keeps sending.\n- `--start` / `--end` bound the campaign in time (ISO 8601). A bare date\n (`2026-09-03`) is midnight at the start of that day in the campaign's\n timezone (`--timezone`, or the campaign's own), so `--end 2026-10-01`\n means \"nothing goes out on or after Oct 1 local time\". Add a time and\n offset (`2026-09-03T09:00:00-07:00`) to be exact. `--clear-start` /\n `--clear-end` remove them.\n- `set` works for the life of the campaign (not once archived). Steps are\n the one thing `set` does not cover; see Steps below.\n- `set --timezone X` alone moves the existing windows to that zone.\n- `duplicate` makes a new draft named \"<name> copy\" (or `--name`) with the same\n steps, schedule, sender pools and AI lines, and no people.\n- `archive` and `delete` stop everyone still in flight and keep every lead and\n all activity; a campaign is never erased.\n\n#### `--window` spec\n\n`\"<days> <start>-<end>\"`, repeatable (up to eight), all in `--timezone`:\n\n| Spec | Meaning |\n|---|---|\n| `\"Mon-Fri 9-18\"` | weekdays, 09:00 until 18:00 |\n| `\"Mon,Wed,Fri 10-16\"` | those three days |\n| `\"Weekdays 9am-5pm\"` | am/pm accepted; `Weekdays`, `Weekends`, `Daily` are groups |\n| `\"Sat-Sun 10-14\"` | day ranges wrap (`Fri-Mon` = Fri, Sat, Sun, Mon) |\n\nHours are whole hours, 0-24; the end must be after the start. Minutes are\nnot supported.\n\n### Add people\n\n```bash\n# search filters: the flags, or --search/--filters JSON (same object, @file.json works)\ndench campaign search --filters @filters.json [--titles Founder,CEO] [--not-industries \"Staffing and Recruiting\"] [--limit 100] [--page-token <t>] [--out audience.json] [--raw]\ndench campaign add <campaign> --search '{\"titles\":[\"Founder\"],\"locations\":[\"United States\"]}' [--limit 50] [--page-token <t>] [--preview] [--allow-active] [--allow-duplicates] [--out added.json]\ndench campaign add <campaign> --titles Founder --locations \"United States\" [--headcount 11-50] [--not-domains example.com] [--limit 50]\n\n# people you already have\ndench campaign add <campaign> --people-file audience.json [--allow-duplicates]\ndench campaign add <campaign> --csv people.csv [--map \"email=Work Email\" ...] [--preview] [--allow-duplicates]\ndench campaign add <campaign> --list <artifactId> [--limit 100] [--enrichment enriched] [--preview] [--allow-duplicates]\n\n# CRM records\ndench campaign add <campaign> --object lead --view \"Q3 targets\" [--email-field Email] [--linkedin-field \"POC LinkedIn URL\"] [--name-field Name] [--allow-duplicates] [--json]\ndench campaign add <campaign> --object people --entries <id1>,<id2> [--relation-field Contact] [--reverse] [--json]\n\n# one person with no CRM row yet (a lead is created); needs --email, --linkedin-url or both\ndench campaign add <campaign> [--name \"Ada Lovelace\"] --email ada@example.com [--linkedin-url https://linkedin.com/in/ada] [--json]\n```\n\n**Search and filters.** `--filters` and `--search` take the same JSON with every\npeople filter and work on both `search` and `add`. The flags `--titles`,\n`--past-titles`, `--person-names`, `--locations`, `--seniorities`,\n`--past-seniorities`, `--profile-keywords`, `--company-keywords`,\n`--industries`, `--functions`, `--sub-functions`, `--company-domains`,\n`--company-names`, `--past-company-names`, `--company-hq`, `--company-types`,\n`--universities`, `--skills`, `--languages`, `--headcount`, the ranges\n`--years-in-role`, `--years-at-company`, `--days-since-job-change`,\n`--founded-years` (`min:max`), and `--exact` add to that JSON: list flags\nappend to the JSON lists, so exclusions in the JSON survive. `--not-<flag>` and\n`--exclude-<flag>` leave values out of any list filter. A filter name that is\nnot allowed lists the allowed ones and the nearest match. `dench leads filters`\nprints accepted values.\n\nA flag value is split at its commas: `--titles \"CTO,VP Engineering\"` is two\ntitles, and a Note on stderr shows how a value was split (not for domains or\nexact filter values such as seniorities). Names with a comma that match a known\nvalue stay whole (the industry \"Technology, Information and Internet\"). A\ntitle, place or company name that contains a comma must be wrapped in double\nquotes inside the shell quotes, `--titles '\"Vice President, Information\nSystems\"'` or `--not-company-names '\"Acme, Inc.\"'`, or go in the `--filters`\nJSON. Otherwise it becomes several values and widens a billed search.\n\n**Limits and cost.** `search` returns at most 100 people per call and `add\n--search` adds at most 50 (a higher `--limit` is capped, with a note). Search\nand `--preview` cost 1 cent per person returned; `add --search --preview` means\n**no enrollment**, not a free search. Adding with `--people-file`, `--csv`,\n`--list`, `--object` or a single person is free of search cost. Adding with a\nsearch into a campaign that is already active, paused or completed needs\n`--allow-active`, because new people start its steps right away. Every add\nresult carries `campaignStatus`.\n\n**`--people-file`** accepts a recipient array or the result of `campaign search`\n(its `recipients`), 1-300 people. A recipient may contain `email`,\n`linkedinProfileUrl` (also `linkedinUrl`, `linkedin`), `displayName` (also\n`name`, `fullName`) and `personalization` (merge values); other text columns\nbecome merge values named after the key. An unknown value type is refused with\nthe row number instead of being dropped. New identities become Leads.\n`--allow-duplicates` only disables the cross-campaign duplicate check, not\nsuppression or campaign-local deduplication.\n\n**`--csv`** reads a spreadsheet export the way the app's Add people does: the\nemail and LinkedIn columns are found from what they hold, whatever they are\ncalled; the name comes from First name + Last name columns or from one `Name`,\n`Full name` or `Contact` column, found by its header (that column also stays\navailable as a merge value); every other column becomes a merge value\n(`{{Company}}`, `{{Job Title}}`). `--map\nemail|linkedin|name|first|last=\"<header or column letter>\"` overrides a guess\n(`none` switches a field off); `name` is the whole name in one column and cannot\nbe combined with `first` or `last`. `--preview` shows how each column is read\nand adds nobody, and the `Read` note says when no name column was found. Comma,\nsemicolon and tab files work, up to 5 MB and 500 people.\n\n**`--list`** adds people from a saved list (`dench lists`, made by `dench leads\nfind --save-as`) without searching or paying again. New people become Leads\nduring enrollment, in batches of 50. Custom values saved under each person's\n`personalization` object are preserved, including `role_title` and `Fund`.\n`--enrichment` keeps only rows at that stage\n(`all`, `enriched`, `in_progress`, `no_contacts`, `failed`, `not_enriched`).\n\n**CRM records.**\n\n- One person needs at least one of `--email` / `--linkedin-url`. `--name`\n is only for this form; with `--object`, pick the name column with\n `--name-field`.\n- A campaign holds at most **300 people**. `add` stops at the cap and says\n so (`cappedAtLimit`). Adding works on drafts and on launched campaigns\n (new people start at step 1); not on archived ones.\n- `--view` reads the saved view's own filters, sort and pinned rows, the\n same rows `dench crm views entries <object> \"<view>\"` returns. A view\n over more than 1000 rows cannot be listed fully (`truncated`); the\n command warns and only the listed rows are considered — narrow the view.\n- Each record needs an email (`--email-field`, default the `Email`\n column) and/or a LinkedIn profile URL (`--linkedin-field`, default the\n LinkedIn URL column). Records with neither are skipped\n (`skippedNoIdentity`). `--relation-field Contact` follows a relation to\n the person record first; `--reverse` walks it the other way.\n- By default a person already **queued or enrolled in another draft, active or\n paused campaign** is skipped (`duplicatesElsewhere`); `--allow-duplicates`\n adds them anyway. Remove them from one draft's audience, archive an old draft,\n or stop their enrollment in a launched campaign to resolve the conflict.\n Someone already in this campaign is never added twice (`duplicates`; `merged`\n counts the ones that gained a missing email or URL). Unsubscribed or\n bounced people are skipped (`suppressed`).\n- The result says how many were added and why the rest were not. Read it\n back to the user before launching.\n\nEvery enrolled person **gets a lead**: a `lead` row is used as-is; a\n`people` row finds the lead whose `Contact` is that person or creates one\n(`Status = New`, `Source = Outbound`, `Contact` linked); a bare `--email` /\n`--linkedin-url` creates the lead too. Workspaces without a `lead` object\nstamp the person instead.\n\n### Steps\n\n```bash\ndench campaign steps get <campaign> [--with-ids] # JSON you can edit and save: an array, or {\"stepModel\":\"workflow\",\"steps\":[...]} for a workflow\ndench campaign steps set <campaign> --file steps.json [--allow-single-braces] [--json] # replaces every step; DRAFTS ONLY\ndench campaign steps edit <campaign> --file steps.json [--allow-single-braces] [--json] # text and waits in place, also after launch\n```\n\n`steps set` replaces every step and works only while the campaign is a draft.\n`steps edit` keeps the number, order and type of every step and changes their\ntext, waits, reactions, withdrawal settings and conditions, also after launch (people already waiting keep the\ntiming they started with; messages already sent, or already being prepared, keep\ntheir text). In `steps edit` each step in the file is its full new content:\nleaving out a subject (including `inmailSubject`), body, note, `onlyIf` or\n`emailReplyToPrevious` clears it. Senders, LinkedIn wait settings, reaction\nsettings and `withdrawAfterHours` are kept when omitted, and so are a workflow's paths and\nan If / else's settings; set `withdrawAfterHours: null` to turn withdrawal\noff. Steps match by order (a workflow's by `key`, so the file can keep the\norder it was written in), or by `stepId` from `steps get --with-ids` to edit\nonly some; a step saved since you read it is refused, not overwritten. After\nlaunch a workflow's paths (`key`, `next`, `yesNext`, `noNext`) and what an\nIf / else checks (`check`, `conditionField`, `conditionOperator`) stay fixed;\nits `conditionValue` and a `wait_for_connection`'s `connectionTimeoutHours`\ncan still change. On a draft, changing `check` or `conditionOperator` drops\nthe saved settings the new check doesn't use.\n\nFor a plain list, `steps.json` is a JSON array of step objects, in send\norder (max 20). A workflow wraps them as\n`{\"stepModel\":\"workflow\",\"steps\":[...]}` (see Workflows below). Each step\nhas a `type` and only the fields that type uses. For a campaign with sender\npools configured as above, omit step sender ids. A plain list:\n\n```json\n[\n { \"type\": \"linkedin_visit\" },\n {\n \"type\": \"linkedin_connection\",\n \"linkedinMessageBody\": \"Hi {{First name}}, enjoyed your post on {{Topic || \\\"AI\\\"}}.\"\n },\n { \"type\": \"wait\", \"waitHours\": 48 },\n {\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Thanks for connecting, {{First name}}. Quick question: …\",\n \"linkedinMessageMode\": \"wait_until_connected\",\n \"connectionTimeoutHours\": 336\n },\n {\n \"type\": \"email\",\n \"emailSubject\": \"Quick question, {{First name}}\",\n \"emailTextBody\": \"Hi {{First name}}, …\",\n \"onlyIf\": \"not_connected\"\n },\n { \"type\": \"wait\", \"waitHours\": 72 },\n {\n \"type\": \"email\",\n \"emailReplyToPrevious\": true,\n \"emailHtmlBody\": \"<p>Bumping this, {{First name}} — worth a look?</p>\"\n }\n]\n```\n\n| `type` | Required | Optional |\n|---|---|---|\n| `wait` | `waitHours` (> 0, up to 2160 = 90 days) | — |\n| `email` | `emailSubject` (unless `emailReplyToPrevious`); `emailHtmlBody` and/or `emailTextBody` | `emailReplyToPrevious` (thread under the last email sent to this person, no new subject); `onlyIf` |\n| `linkedin_visit` | — | — |\n| `linkedin_connection` | — | `linkedinMessageBody` (the invite note, ≤ 300 chars; the request goes out without it if LinkedIn refuses the note); `withdrawAfterHours` (168–2160, or `null` to turn off) |\n| `linkedin_message` | `linkedinMessageBody` (≤ 3000 chars) | `linkedinMessageMode`; `connectionTimeoutHours` (plain lists; a workflow uses `wait_for_connection`) |\n| `linkedin_like_post` | — | `likeReaction`; `likeMaxPostAgeDays`; `likeSkipPreviousWait`; `likeSkipNextWait`; `likeCount` (1–3 recent posts, default 1); `onlyIf` |\n| `linkedin_inmail` | `linkedinMessageBody` (≤ 1900 chars) | `inmailSubject` (≤ 200 chars; use this, not `emailSubject`) |\n| `condition` (If / else, workflows only) | `check`; `yesNext` (Yes) and `noNext` (No); with `check: \"field_value\"`, `conditionField`, `conditionOperator` and (except `is_empty` / `is_not_empty`) `conditionValue` | — |\n| `wait_for_connection` (Wait for them to accept, workflows only) | `yesNext` (Accepted) and `noNext` (Not accepted) | `connectionTimeoutHours` (the window: 24–2160 = 1–90 days, default 720) |\n\nIn a workflow every step also takes a `key` and a `next`; `condition` and\n`wait_for_connection` take `yesNext` and `noNext` instead of `next`.\n\nLegacy campaigns without a pool for a channel still require\n`emailMailboxAccountId` on email steps and `linkedinAccountId` on LinkedIn\nsteps, on Wait for them to accept (`wait_for_connection`) steps and on If / else\nsteps that check `linkedin_connected`. `steps get` / `steps set` preserve those\nvalues until conversion.\n\n- **What `steps set` and `steps edit` refuse** (so nothing is lost or sent\n raw): a field the step type would drop (`onlyIf` off an email or post-like step, a body on\n a visit, `emailReplyToPrevious` on the first email, condition fields its\n `check` or `conditionOperator` ignores), a missing subject or\n body, an invite note over 300, a message over 3000, an InMail body over 1900\n or InMail subject over 200 characters, out-of-range reaction/withdrawal/\n acceptance-window settings, `likeCount` outside 1–3,\n a wait of 0 or over 2160 hours, more than 20 steps, `{TOKEN}` with single\n braces, and workflow paths that don't hold together (Workflows below). It\n warns when several LinkedIn messages after a connection request each wait 30\n days for the accept, and when a plain list saved on a workflow campaign has\n a message after the connection request, which then no longer waits for the\n accept (Workflows below). An email with both `emailHtmlBody` and `emailTextBody`\n sends the HTML: when you edit only the text, the HTML copied from `steps get`\n is dropped (with a warning) and the new text is sent.\n- `onlyIf` — email and post-like steps in a plain list: `always` (default),\n `connected` (run only if the person accepted the LinkedIn connection),\n `not_connected` (send only if they have not). `connected` without an\n earlier `linkedin_connection` step is a launch warning. In a workflow,\n branch with an If / else (`\"check\": \"linkedin_connected\"`) instead.\n- `linkedinMessageMode` — plain lists: what a `linkedin_message` does while\n the invite is still pending: `wait_until_connected` (default when a\n `linkedin_connection` step comes before it) waits up to\n `connectionTimeoutHours` (1–2160 hours, default 720 = 30 days) then skips;\n `skip_if_not_connected` (default otherwise) skips right away. In a\n workflow a message never waits on its own (the default is\n `skip_if_not_connected`): put it on the Accepted path of a\n `wait_for_connection`, or the Yes path of a `linkedin_connected` If / else.\n- `withdrawAfterHours` — connection requests only. After 168–2160 hours\n (7–90 days), withdraw a still-pending invitation sent by this campaign.\n It never withdraws an unrelated invitation or an accepted connection.\n Omitted on creation or `null` means off; there is no automatic withdrawal\n default. A value of `600` means 25 days after the invitation was sent.\n- `likeReaction` — one of `like` (default), `celebrate`, `support`, `love`,\n `insightful`, `funny`. `likeMaxPostAgeDays` is a whole number from 1 to 365,\n default 30. `likeCount` (1–3, default 1) is how many posts to react to.\n The step chooses their newest eligible original posts and skips when none\n is available or (with one post) it was already reacted to. With\n `likeCount` above 1 a post already reacted to doesn't use one up, and\n fewer recent posts means fewer reactions.\n `likeSkipPreviousWait: true` checks for eligible posts before the wait\n immediately before this step starts. If there are none, it skips that wait\n and the like step, **keeping the following waits**, even when\n `likeSkipNextWait` is true. Earlier consecutive waits remain. Omitted means\n false, so existing campaigns keep their behavior. For example, Wait 2 days →\n Like → Wait 1 day → Message becomes Wait 1 day → Message when no eligible\n posts are found. New like steps created in the editor enable this option\n and set `likeSkipNextWait` to false.\n `likeSkipNextWait` defaults to `true` when omitted: **a reaction skipped\n during normal execution also skips\n consecutive wait steps immediately after it**, including a skip caused by\n `onlyIf`. Set it to `false` to preserve those waits. Omitting these fields\n in `steps edit` preserves their saved values.\n- InMail automatically skips people who are already connected. Do not add\n `onlyIf` or `linkedinMessageMode` to an InMail step. LinkedIn Premium InMail\n through the personal inbox is supported, not Sales Navigator or Recruiter\n InMail. Available InMail credits are checked; an open profile may be free.\n If InMail is unavailable or has no credits, the step skips rather than\n falling back to another send. Read the warnings from `launch --check`.\n- **Merge tokens** work in subjects, bodies and LinkedIn text:\n `{{First name}}`, `{{Company}}`, `{{Job Title}}` — any column of the\n enrolled record or value supplied with the person, plus `firstName`,\n `lastName`, `name`, `company`, `email`. Chain fallbacks with `||`:\n `{{First name || \"there\"}}`. A plain token with no value for a person is a\n **launch blocker** for that person (a quoted fallback avoids it); on a\n launched campaign such people are skipped at `add` time\n (`skippedMissingInfo`). AI-line tokens use their saved fallback until the line\n is written and never block launch.\n\n#### Workflows (branching paths)\n\nA workflow is a campaign whose steps say where each one goes, so different\npeople take different paths through the same campaign (the app shows it as\nthe campaign's Sequence tab). Use one whenever the brief has an \"if\".\n\n**How the Sequence tab draws them.** Each ordinary `wait` is a separate,\nclickable step (for example, \"Wait 2 days\") between actions. Add one from\n**+ → Flow → Wait**, then click it to edit the amount and unit. Waits can\nalso go before End; deleting an action keeps the wait before it.\nA `linkedin_connection` card carries the `wait_for_connection` right after\nit (**Wait up to** N days, paths Accepted / Not accepted) and, when the only\nway into the request is the No exit of a `linkedin_connected` If / else,\nthat check too (**If already connected → Separate steps for existing\nconnections**, a third path).\nThe acceptance window stays on the connection request; the add menu does\nnot offer a separate Wait for them to accept step. The stored steps below\nkeep the same timing and paths.\n\n**Keyboard editing in a draft.** Select a node and press Delete or Backspace\nto remove it; a branching node asks which path to keep. Use **⌘Z** to undo and\n**⌘⇧Z** to redo (**Ctrl+Z** / **Ctrl+Shift+Z** or **Ctrl+Y** on Windows).\nUndo restores the node's content and connections, including after deleting\nthe last node. In a message or other text field, the shortcuts edit the text\nnormally. Sequence history is kept for the current campaign editing session.\n\n**Keys and paths.** Give every step a `key`: a short id like `\"invite\"`,\nunique in the campaign, never `\"end\"`. Then say where it goes:\n\n- `condition` (If / else) and `wait_for_connection` (Wait for them to accept)\n have two exits, both required: `yesNext` and `noNext` (Yes / No, or\n Accepted / Not accepted). They take no `next`.\n- Every other step has one exit, `next`. Left out, it is the step listed\n after it in the file, or `\"end\"` after the last one.\n- An exit is another step's `key`, or `\"end\"`: that path stops there and the\n person is done with the campaign. Any path can end anywhere, so one branch\n can stop after an InMail while the other goes on.\n- **Merges**: several exits may point at the same step. Write a message once,\n then point the If / else's Yes exit and the Wait for them to accept step's\n Accepted exit at it; everything after it is shared.\n\n**If / else** (`\"type\": \"condition\"`) sends nothing. It checks the person\nwhen they reach it and takes Yes or No (`check`):\n\nIn the editor, a new If / else starts with **Choose a condition**. Select a\ncheck in its settings; the unfinished step can be saved as a draft, but a\ncondition must be chosen before launch.\n\n| `check` | Yes when |\n|---|---|\n| `linkedin_connected` | they are connected to the sender on LinkedIn (No without a LinkedIn profile) |\n| `has_email` | they have an email address that can still be emailed (not bounced, unsubscribed or marked as spam) |\n| `opened_last_email` | they opened the last email sent to them. Needs an email before it on every path and open tracking; put a wait between the email and the check so people have time to open it (`launch --check` warns otherwise) |\n| `field_value` | a field on their lead matches (Field value): `conditionField` (the field's name, like `\"Job Title\"` or `\"Source\"`), `conditionOperator` and, except for the empty checks, `conditionValue` |\n\nField value reads the person's lead, or their own record if they have no\nlead, when they reach the If / else. The campaign itself changes `Status`,\n`Last touch` and `LinkedIn connection` as it runs (How it shows up in the CRM,\nbelow): after the first send everyone is `Contacted`, so don't branch on\nthose to mean \"before we wrote to them\". Pick a field the campaign doesn't\nwrite.\n\nField value operators (`conditionOperator`), all case-insensitive:\n\n| `conditionOperator` | Yes when the field |\n|---|---|\n| `is` | equals `conditionValue` (on a multi-value field: any of its values does) |\n| `is_not` | does not equal it (none of its values do) |\n| `contains` | contains it as text (any of its values does) |\n| `is_empty` | has no value |\n| `is_not_empty` | has a value |\n\n**Wait for them to accept** (`\"type\": \"wait_for_connection\"`) sends nothing.\nFrom when the person reaches it, it waits up to `connectionTimeoutHours`\n(the window: 24–2160 hours = 1–90 days, default 720 = 30 days) for the\nconnection request to be accepted. It takes Accepted as soon as they accept\n(right away if they were already connected) and Not accepted when the window\ncloses, the invitation is withdrawn or it never went out. It needs a\n`linkedin_connection` before it on every path. Keep that request's\n`withdrawAfterHours` longer than the window, or leave it off: a withdrawal\nduring the wait ends it as Not accepted.\n\n**Rules.**\n\n- Paths only move forward: no loops, no exit back to an earlier step, and\n every step reachable from the first. At most 20 steps, If / else and Wait\n for them to accept included.\n- The server stores the steps in path order, which can differ from the\n file's; the paths, not the order, decide who gets what. `steps get` shows\n the stored order and `dench campaign get` lists each step's paths.\n- A reply-in-thread email (`\"emailReplyToPrevious\": true`) needs an email\n before it on every path that reaches it; it threads under the last email\n sent to that person.\n- Branch with If / else and Wait for them to accept, not `onlyIf` and\n `linkedinMessageMode`: in a workflow a `linkedin_message` never waits for\n the accept on its own. A plain list file (no keys or paths) saved on a\n workflow campaign runs as a workflow too, so a message after its connection\n request skips anyone who hasn't accepted yet: edit the file `steps get`\n prints instead. `steps set` warns about such a list, and `launch --check`\n about any message some path reaches after a connection request without a\n Wait for them to accept or a `linkedin_connected` If / else.\n- Steps with a `key`, a path or one of these two types save the campaign as\n a workflow, and a workflow stays one (`\"stepModel\": \"linear\"` is refused).\n For a plain list again, start a new campaign with `dench campaign draft`\n and set the steps there. Don't use `dench campaign duplicate`: the copy is\n still a workflow, so a plain-list `linkedin_message` would no longer wait\n for the accept. `steps get` prints a workflow\n as `{\"stepModel\":\"workflow\",\"steps\":[...]}`; `steps set` and `steps edit`\n take that file back as is.\n- After launch the structure is fixed: step types, keys, paths (`next`,\n `yesNext`, `noNext`) and what each If / else checks (`check`,\n `conditionField`, `conditionOperator`). `steps edit` still changes text,\n waits, `conditionValue` and the window of a Wait for them to accept. To\n change the structure, `dench campaign duplicate <c>`, fix the copy and add\n only people who were never contacted.\n\n**Workflow launch blockers** (`launch --check` names the step):\n\n| Blocker | What's wrong | Fix |\n|---|---|---|\n| `workflow_path_invalid` | the paths don't hold together: two steps share a key, an exit names a key no step has, a path goes back or loops, nothing leads to a step, or an If / else or Wait for them to accept misses an exit. Also fires when a plain list holds one of those two steps | fix `key`, `next`, `yesNext` and `noNext` in the file, then `steps set` |\n| `wait_for_connection_without_invite` | a path reaches a Wait for them to accept with no connection request before it | add a `linkedin_connection` earlier on that path |\n| `opened_check_without_email` | a path reaches an `opened_last_email` If / else with no email before it | send an email earlier on every path to it, or check something else |\n| `open_tracking_unavailable` | email opens aren't tracked, so `opened_last_email` would always say No | check something else |\n| `condition_field_missing` | a `field_value` If / else names a field the campaign's leads don't have | `dench crm fields list lead` (for people with no lead, the object they were added from, like `dench crm fields list people`), then use one of those field names |\n| `reply_without_prior_email` | a path reaches a reply-in-thread email with no email before it | send an email earlier on every path to it, or give it its own `emailSubject` |\n\n**Example: connected or not, an acceptance window and an InMail fallback.**\nPeople already connected get the message right away. Everyone else gets a\nconnection request (withdrawn after 25 days if still pending); those who\naccept within 10 days get the same message, the rest get an InMail and\nstop. After the message: a 2-day wait, a reaction to two recent posts, a\nday, then a follow-up. Supply `Fund` for each person (or use a deliberate\nfallback); do not guess investor data. Sender pools still come from the\ncampaign settings.\n\n```json\n{\n \"stepModel\": \"workflow\",\n \"steps\": [\n {\n \"key\": \"connected\",\n \"type\": \"condition\",\n \"check\": \"linkedin_connected\",\n \"yesNext\": \"pitch\",\n \"noNext\": \"invite\"\n },\n {\n \"key\": \"invite\",\n \"type\": \"linkedin_connection\",\n \"withdrawAfterHours\": 600,\n \"next\": \"accept\"\n },\n {\n \"key\": \"accept\",\n \"type\": \"wait_for_connection\",\n \"connectionTimeoutHours\": 240,\n \"yesNext\": \"pitch\",\n \"noNext\": \"inmail\"\n },\n {\n \"key\": \"inmail\",\n \"type\": \"linkedin_inmail\",\n \"inmailSubject\": \"Fellow {{Fund}} founder\",\n \"linkedinMessageBody\": \"Hi {{First name}}, fellow {{Fund}} founder here. We wrote a short report on how teams like {{Company}} handle this. May I send it?\",\n \"next\": \"end\"\n },\n {\n \"key\": \"pitch\",\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Hi {{First name}}, fellow {{Fund}} founder here. We wrote a short report on how teams like {{Company}} handle this. May I send it?\",\n \"next\": \"pause\"\n },\n { \"key\": \"pause\", \"type\": \"wait\", \"waitHours\": 48, \"next\": \"like\" },\n {\n \"key\": \"like\",\n \"type\": \"linkedin_like_post\",\n \"likeReaction\": \"like\",\n \"likeMaxPostAgeDays\": 30,\n \"likeCount\": 2,\n \"next\": \"pause2\"\n },\n { \"key\": \"pause2\", \"type\": \"wait\", \"waitHours\": 24, \"next\": \"report\" },\n {\n \"key\": \"report\",\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Hi {{First name}}, is the report useful for {{Company}}?\",\n \"next\": \"end\"\n }\n ]\n}\n```\n\nExplain the mapping to the user like this: \"if connected\" is the\n`connected` If / else; \"else a connection request\" is its No exit to\n`invite`; \"wait 10 days\" is `accept` (`connectionTimeoutHours: 240`); its\nAccepted exit merges into the same `pitch` as the Yes exit; Not accepted goes\nto `inmail`, which ends. Everything from `pitch` on is one shared path. In\nthe app that is one \"Send connection request\" card with Already connected,\nAccepted and Not accepted paths and \"Wait up to 10 days\"; the 2-day and\n1-day waits appear as separate steps before the Like and follow-up cards.\n\nSave on a draft, inspect the round trip, then check readiness without sending:\n\n```bash\ndench campaign steps set <campaign> --file steps.json --json\ndench campaign steps get <campaign> --with-ids\ndench campaign launch <campaign> --check --json\n```\n\nThe REST operations `campaigns.steps.replace` and `campaigns.steps.update` use\nthe same field rules. When replacing a workflow's steps, send\n`\"stepModel\": \"workflow\"` so they are checked the way they will be saved.\nUpdates require `stepId`, `type` and `expectedUpdatedAt`; only supplied fields\nchange. Defaults are not re-applied to a partial update.\nKeep the campaign at a reviewed draft until the user approves real sends.\n- **Account ids.** `dench campaign accounts --json` returns `mailboxes` with\n `emailMailboxAccountId` and `linkedinAccounts` with `linkedinAccountId`.\n Both lists honor the acting member's connection visibility: their own\n private accounts and teammates' shared accounts, never someone else's\n private account. LinkedIn discovery also excludes removed accounts,\n former members' accounts and mock connections. It needs a live member's\n API key or agent session; an organization-only key is refused.\n LinkedIn summaries contain display/owner labels, status, availability,\n `remainingToday` (`invites`, `messages`, `profiles`) and\n `remainingInvitesThisWeek`. Today's invites also respect the rolling\n seven-day limit. Mailbox summaries include warm-up status, when a new\n mailbox is ready and its daily cold-send cap. These are account-local usage\n snapshots before queued work and campaign limits, not send reservations. Pool\n updates validate both the editor's and campaign owner's access; launch and\n dispatch still validate availability. Use only the Dench account ids in a\n campaign pool.\n API equivalent for LinkedIn discovery: `GET $DENCH_API_BASE/campaigns/accounts/linkedin`\n with the same bearer credentials; no caller-supplied user or workspace id.\n\n### AI-written lines\n\n```bash\ndench campaign personalize get <campaign>\ndench campaign personalize set <campaign> --file lines.json\ndench campaign personalize write <campaign> [--all] [--yes]\ndench campaign personalize edit <campaign> --person <enrollmentId|name> --line <key> --text \"…\"\ndench campaign personalize rewrite <campaign> --person <enrollmentId|name> [--line <key>]\ndench campaign personalize clear <campaign>\n```\n\nUp to 5 lines per campaign, about 3 cents a person. `lines.json` is\n`{\"sells\":\"…\",\"lines\":[{\"label\",\"instructions\",\"fallback\"}]}`; optional per\nline: `key` (otherwise made from the label), `maxChars` 20-300 and `fallbackFrom`\n(a field to use before the fallback). `set` writes lines for up to 100 people\nright away; more waits for `write --yes`, which confirms the cost. `write --all`\nrewrites everyone; `edit --text \"\"` undoes a manual edit. `clear` turns lines\noff; take the `{{keys}}` out of the steps first.\n\n### Per person\n\n```bash\ndench campaign stop <campaign> --person <enrollmentId|name> [--json] # nothing more is sent to them\ndench campaign remove <campaign> --person <enrollmentId|name> [--json] # drafts only: drop someone never contacted\ndench campaign resume-person <campaign> (--person <enrollmentId|name> | --all) [--json]\ndench campaign person set <campaign> --person <enrollmentId|name> [--email ada@new.com] [--linkedin-url <url>] [--field \"Job Title=CTO\" ...] [--json]\ndench campaign sync <campaign> [--json] # fill empty email, LinkedIn URL, name and fields from CRM records\n```\n\nEnrollment ids come from `dench campaign people`. A person's name works\nwhen it is unique in the campaign. `stop` on a never-contacted person in a\ndraft removes them, which frees their place in the 300-person cap. `remove`\nrefuses anyone already contacted. `resume-person --all` resumes every paused\nperson in an active campaign, for example after a sender was reconnected.\n`person set` fixes an address or fills a `{{merge field}}` before launch (a\ncorrected email, LinkedIn URL or matching column also updates the linked CRM\nrecord); `--field` repeats. `sync` fills each unfinished person's empty email,\nLinkedIn URL, name and merge fields from their linked CRM record, for example\nafter enriching the records; it never overwrites a value the campaign already\nhas.\n\n### Launch and lifecycle\n\n```bash\ndench campaign launch <campaign> --check [--json] # readiness only; never launches\ndench campaign launch <campaign> [--ack-linkedin-risk] [--json]\ndench campaign pause <campaign> [--json]\ndench campaign resume <campaign> [--json]\ndench campaign archive <campaign> [--json] # stops everyone still in flight; final\n```\n\n`launch --check` runs only the readiness check and never launches. It\nprints each blocker with why it fires and the commands that fix it\n(`reasons` and `fix` on every entry of `blockers[]` in `--json`), the\nwarnings, the audience and step counts and the `fingerprint`, then exits 0\nwhen the campaign is ready and 1 when it is blocked. Run it before every\nlaunch: plain `launch` launches as soon as the campaign is ready, so it is\nnot a dry run. `start` is another name for `launch`, including `--check`.\n\n`launch` runs the same check first. When something is missing it\nprints every blocker in plain words — no steps, nobody enrolled, a step's\nmailbox or LinkedIn account missing or disconnected, people without an\nemail or URL, people missing a merge field the steps use, a reply-to-thread\nstep with no earlier email, people enrolled in another LinkedIn campaign —\nand exits 1 without launching. Fix them (`steps set`, `add`, `set`) and run\n`launch` again. `--json` prints the full readiness payload (`blockers[]`\ngrouped by problem with the affected people, `warnings[]`).\n\nCampaigns with LinkedIn steps need `--ack-linkedin-risk`: automated\nLinkedIn activity is against LinkedIn's terms and can get the account\nrestricted. Say so to the user and pass the flag only once they accept.\n\nStatus moves `draft → active → (paused ↔ active) → completed`, and\n`archived` from anywhere. `pause` only acts on an active campaign, `resume`\nonly on a paused one; both say when there is nothing to do. `completed`\nmeans everyone finished, replied or stopped; adding people to a completed\ncampaign revives it.\n\n## Reading `dench campaign get`\n\n```\nFounder outreach — active [js7…]\nSchedule: Mon-Fri 9-18 America/Los_Angeles · up to 30 emails/day · stops on reply\nSteps (4): Visit profile → Connect on LinkedIn → Wait 2d → Email\n\nFunnel\n Enrolled 120\n In flight 38 (active 36, paused 2)\n Contacted 80\n LinkedIn invited 60 · accepted 22 · messaged 18\n Email sent 75 · opened 30 · clicked 4\n Replied 9 (11.3% of contacted)\n Done finished 30 · stopped 5 · failed 1\n\nNow / Next\n Now: Sending a connection request to Grace Hopper (since Sep 2, 2026, 10:41 AM)\n Next: Send an email to Ada Lovelace at Sep 2, 2026, 10:44 AM (in 3m)\n Held: today's email cap is reached · resumes Sep 3, 2026, 9:00 AM (in 22h)\n Emails today: 30/30 · next email Sep 3, 2026, 9:00 AM (in 22h)\n Sender Mark R: running · invites 12/25 today, 40/100 this week · messages 3/40 today · 09:00-18:00 America/Los_Angeles (in window)\n\nPeople (50 of 120)\n Ada Lovelace — active · waiting: email · until Sep 2, 2026, 10:44 AM (in 3m) · last: invite sent 2d ago · lead: Contacted [enr_…]\n Grace Hopper — active · sending: connect on linkedin · hold: the sender's daily LinkedIn limit is reached (until …) [enr_…]\n Linus T — replied · last: LinkedIn message sent 5h ago · lead: Replied [enr_…]\n```\n\n- **Funnel**: `Enrolled` = everyone ever added. `Contacted` = got at least\n one email, invite or message (a profile visit does not count). `Replied`\n counts replies from people this campaign contacted, whether or not the\n reply stopped them; the rate is replied / `Contacted`. `Done` splits\n finished (reached the end), stopped (stopped, bounced, complained,\n unsubscribed) and failed. In a plain list a finished person ran every\n step; in a workflow they reached the end of their path, so someone on the\n Not accepted → InMail path finishes without the steps on the other path.\n- **Now** is the one action being sent this instant; **Next** is the next\n action and when. `Held` explains why nothing is going out.\n- **Hold reasons** (on `Next`, on a person, or as `Held`), in plain words:\n the campaign is paused · a sending account is disconnected · today's email\n cap is reached · outside the sender's working hours · outside the\n campaign's send window · the sender's daily LinkedIn limit is reached ·\n the sender's weekly connection limit is reached · spacing out sends so\n they look human · checking whether they are already connected · paused\n after LinkedIn errors · the LinkedIn account is paused · LinkedIn asked\n us to retry later · writing personalized lines (shown on a person as\n `note: Waiting for personalized lines`; after 2 hours the saved fallback\n text is sent). Every one of these clears on its own; none means a\n step \"did not send\". Report the hold, not a failure.\n- **People**: status, what their current step is doing, the last delivered\n step, any hold, and the linked lead's `Status`. `--json` returns `{\n detail, analytics, live }` — the raw campaign (`detail.enrollments`,\n `detail.currentRuns[enrollmentId].hold`, `detail.lastTouches`,\n `detail.connectedEntries[enrollmentId].lead`), the funnel and the live\n strip.\n\nA workflow's `get` lists its paths, counts each exit and shows the\nacceptance waits:\n\n```\nSteps (9, a workflow with paths):\n 1. If / else: Connected on LinkedIn? → Yes: LinkedIn message (step 5) · No: Connect on LinkedIn (step 2)\n 2. Connect on LinkedIn\n 3. Wait for them to accept (up to 10d) → Accepted: LinkedIn message (step 5) · Not accepted: LinkedIn InMail (step 4)\n 4. LinkedIn InMail → End\n 5. LinkedIn message\n …\n\nFunnel\n …\n Done finished 3 · stopped 0 · failed 0\n Paths step 1 If / else: Connected on LinkedIn? → Yes 12 · No 40\n step 3 Wait for them to accept → Accepted 9 · Not accepted 14\n\nNow / Next\n Next: Wait for Ada Lovelace to accept the connection request — next check Sep 2, 2026, 12:41 PM (in 2h), stops waiting Sep 7, 2026, 10:41 AM (in 5d)\n\nPeople (50 of 52)\n Ada Lovelace — active · waiting: Wait for them to accept · stops waiting Sep 7, 2026, 10:41 AM (in 5d) [enr_…]\n Grace Hopper — active · checking: If / else: Connected on LinkedIn? [enr_…]\n```\n\n- **Steps**: one line per step in the stored order. A step names where it\n goes only when that isn't the next line; `→ End` ends that path. If /\n else and Wait for them to accept name both exits.\n- **Paths**: how many people have taken each exit so far (`branchStats` in\n `--json` analytics). The two numbers can add up to less than `Enrolled`:\n people before the step, or on another path, haven't reached it.\n- **Next** for a Wait for them to accept: when Dench next checks for the\n accept, and when it stops waiting and takes Not accepted. `Check\n \"<label>\" for <name>` is an If / else about to run.\n- **People**: `checking: <If / else>` while an If / else or Wait for them to\n accept reads the profile (nothing is sent); `waiting: Wait for them to\n accept · stops waiting …` until they accept or the window closes.\n\n## How it shows up in the CRM\n\n- **Lead `Status` moves on its own, forward only**: the first delivered\n email, connection request or LinkedIn message moves New → `Contacted`; a\n reply moves it to `Replied`. Nothing sets `Qualified` / `Disqualified` or\n moves backwards, and a `Status` outside New/Contacted/Replied is left\n alone. `Last touch` is bumped on every send, acceptance and reply. Never\n hand-edit `Status` after a step ran — you would race the writeback.\n- **Lead `LinkedIn connection` tracks the relationship, forward only**: a\n connection request sets `Invited`; an acceptance — or finding the person\n is already a connection — sets `Connected`. The column is created on the\n lead object the first time a LinkedIn step runs; email-only campaigns\n never touch it.\n- Every touch is also an event on the lead's History tab (source\n \"Campaign\") and in `dench campaign events`. `dench crm history <object>\n <entryId>` shows the field changes under the actor `Campaign: <name>`.\n- Enrolling a `people` row links its lead's `Contact` to that person; that\n link is expected — leave it.\n\n## REST API and app SDK\n\nAll paths are under `/api/v1` and need member-bound credentials. Agents can call\nany operation through `dench.api.call(operationId, args)`, and the typed\nmethods are under `dench.campaigns` (see [APPS.md](./APPS.md)). The full\nrequest and response schemas are in [API.md](./API.md) and `openapi.json`.\nOperation ids below are `campaigns.<name>`:\n\n| What | Operations |\n|---|---|\n| Browse and inspect | `list`, `get`, `analytics`, `live`, `events`, `preview`, `pipeline`, `people.timeline`, `people.forRecord`, `accounts.email`, `accounts.linkedin` |\n| Create and configure | `create`, `drafts.create`, `update`, `duplicate`, `archive` |\n| Add people | `audience.search`, `people.addFromSearch`, `people.addBatch` (50 recipients), `people.addFromCrm` (100 ids), `people.add`; saved lists via `lists.rows` and `people.addBatch`, retaining each row's `personalization` |\n| Steps | `steps.replace` (draft), `steps.update` (also after launch) |\n| AI lines | `personalization.get`, `.set`, `.write`, `.edit`, `.rewrite`, `.clear` |\n| Per person | `people.stop`, `people.remove`, `people.resume`, `people.resumeAll`, `people.setEmail`, `people.setLinkedin`, `people.setField`, `people.sync` |\n| Launch | `launch.preview` (`GET /campaigns/{sequenceId}/launch`, returns the `fingerprint`), `launch` (`POST`, needs that `fingerprint`), `pause`, `resume` |\n| Builder | `builder.profile`, `.autofill`, `.estimate`, `.lookalike`, `.voices`, `.save`, `.get`, `.build`, `.opener`, `.sequence`, `.outreach`, `.create`, `.drafts`, `.resume`, `.discard` |\n| Signals | `sources.overview`, `.get`, `.signals`, `.update`, `.preview`, `.run`, `.pending`, `.review`; `queue` |\n\nSearch bodies are `{ \"filters\": { … }, \"limit\": 50 }` with an optional\n`pageToken`; batch bodies are `{ \"recipients\": [ … ] }`. There is no reply-text\nendpoint: combine `campaigns.get` with the CRM activity of the person, or use\n`dench campaign replies`.\n\n## Rules\n\n- `steps set` works only in draft; `steps edit` changes text and waits after\n launch. Schedule, daily cap, stop-on-reply, start and end change any time\n before archive.\n- One campaign, one schedule: all steps share the send windows; LinkedIn\n steps also respect the LinkedIn account's own working hours and limits.\n- Max 300 people per campaign, 20 steps, 100 ids per CRM `add` batch and 50\n people per search or file batch (the CLI chunks for you), 8 send windows,\n 300 characters per invite note, 3000 characters per LinkedIn message.\n- Outreach needs a **workspace member's** credentials: a `dench signin`\n session, a member-bound `DENCH_API_KEY`, or an agent session a member\n created. With an organization-only key every command fails with\n \"Outreach needs a workspace member's credentials\". That is about whose\n credentials the run has, not about sending accounts — connecting a\n mailbox changes nothing. Ask the user to run it from a chat in the Dench\n app (or to link their account in Slack) so the run carries their\n identity, rather than retrying.\n- `dench email multichannel …` drives the same campaigns with fewer\n controls; prefer `dench campaign`.\n- HTTP equivalent: `$DENCH_API_BASE/campaigns…` (the Campaigns section of\n `references/API.md`; operationIds `campaigns_*` in `openapi.json`). `launch` there needs the `fingerprint` from\n `GET /campaigns/{sequenceId}/launch`.\n\n## What still needs the user in the Dench app\n\n- Signing in to a mailbox or LinkedIn account (`dench tool connect` prints the\n link), reconnecting or disconnecting it, and a mailbox's warm-up sign-in.\n- A mailbox's daily cold-send cap, skipping its warm-up and sharing it with\n teammates; a LinkedIn account's daily and weekly limits, working hours and\n risk acknowledgement.\n- Answering replies in the Inbox.\n"
|
|
30
|
+
"sha256": "0d9d121277276b2eb1432b0c8a913acb10af9b94c7278c8af5f5642179a8551a",
|
|
31
|
+
"content": "---\nname: campaigns\ndescription: \"Build, run and fix email + LinkedIn outreach campaigns with `dench campaign` (CLI/API), starting from a raw brief: ask the setup questions with recommended answers from organization memory, then build from any of the five sources (buying signals, lookalike of a best lead, pasted leads or CSV, CRM records, a people search), write steps and personalized lines, set senders, schedule and approval, check launch readiness, launch, run signals now, approve new people, then track replies, the funnel and hold reasons. Use for any request to set up, edit, duplicate, delete or monitor an outreach, cold-email or LinkedIn campaign or sequence.\"\n---\n\n# Dench Outreach Campaigns\n\nAn **outreach campaign** sends a sequence of steps — emails from a connected\nGmail/Outlook mailbox, LinkedIn profile visits, connection requests and\nmessages from a connected LinkedIn account — to a list of people, one person\nat a time, inside a send window. The steps run in order, or as a workflow\nwhose If / else and Wait for them to accept steps send people down different\npaths. It is the Outreach → Campaigns page in the\nDench app, and everything that page does is also a `dench campaign …` command\nor an API call. Every command takes `--json`. Notices and cost lines go to\nstderr and stdout is plain JSON, so `> file.json` is safe.\n\n`draft`, `create`, `duplicate` and `get` include named `references`, a canonical\n`href`, and an absolute `url` when the connected workspace slug is available.\nLink the campaign name using that result rather than displaying its raw ID or\nmaking an extra lookup to construct a URL. `list --with-references --json` wraps\nthe ordinary list in `{data, references, referenceCoverage}`; plain `list --json`\nstill returns the original array. The reference identity is the Outreach\n`sequenceId`, never the separate CRM campaign mirror's entry ID.\n\nCampaign analytics scans the full history in bounded server-side pages. The\nJSON result includes `startedAt` and `computedAt`: totals reflect that\nobservation interval, not an atomic snapshot while sending continues. The\ndashboard refreshes every minute.\n\nNot this skill: one-shot newsletters and raw `dench email send` live in\n`email-campaigns`. Prospecting on its own (no campaign) is `sales` / `dench\nleads find`. A CRM record's history is `crm`.\n\n## Ask first, with recommended answers\n\nBefore building anything, settle the campaign with the user in ONE message of\nshort numbered questions. Every question carries a **recommended answer** the\nuser can accept with \"yes\" or a number. Never send a question without one,\nand never ask what the brief already answers. Say what you inferred instead.\n\n**Where the recommendations come from**, in this order:\n\n1. **Organization memory**: the `## Organisation` section of your system\n prompt, or `read_file /ORGANISATION.md`. It says what the company sells,\n to whom, the market, competitors and voice.\n2. **`dench campaign builder profile --json`** (free). It returns the\n workspace's saved ICP (`targeting`), suggested targeting, `defaultSignals`,\n suggested terms per signal (`suggestions`), and whether a LinkedIn account\n and a mailbox are connected (`hasLinkedin`, `hasMailbox`).\n3. **`dench campaign accounts --json`** for the sender ids.\n\nIf organization memory says nothing about what the company sells or who it\nsells to, ask that first: \"What do you sell, and who buys it?\" Offer to save\nthe answer with `update_organisation`, then derive the rest from it.\nRecommendations must come from these sources. Never fill them with generic\nB2B defaults.\n\n**The questions** (skip any the brief settles; keep each to one line plus the\nrecommendation):\n\n| # | Ask | Recommend |\n|---|---|---|\n| 1 | **Where people come from**: Signals (people showing buying intent), Lookalike (people like your best lead), Existing leads (paste or CSV), From CRM, or Find new people (a filtered search) | Signals when organization memory describes a problem people post or hire for; Lookalike when the user names a best customer; From CRM when they mean people they already know |\n| 2 | **Who**: titles, industries, company sizes, locations, who to leave out | The ICP from organization memory and `builder profile`. Name competitors from memory as exclusions |\n| 3 | **Which signals and terms** (signals only) | `defaultSignals`, plus 2-4 topics from `suggestions` rewritten as **what the buyer does**, e.g. \"using AI for outbound\" rather than \"Claude\" (see Topics below) |\n| 4 | **Channels and goal**: email, LinkedIn or both; what a reply should lead to; tone | Both when `hasLinkedin` and `hasMailbox`, else the connected one; the goal and tone from organization memory |\n| 5 | **Who sends and when**: mailboxes and LinkedIn accounts, days, hours, timezone, daily email cap | Every connected account, Mon-Fri 9-17 in the user's timezone, 30 emails a day |\n| 6 | **Approval** (signals and lookalike): new people start on their own, or wait for approval | Manual review (the app's default) for a new campaign; automatic once the first week's people look right |\n| 7 | **How often signals run** and whether to add matching people without a signal | Daily; add matching people off |\n\nAfter the answers, restate the plan in five lines (source, who, signals,\nchannels and senders, approval) and say what will cost money before any\nbillable step.\n\n## Build a campaign from a brief\n\nThe brief can be an ICP document, a list of titles and companies, a sequence\nexported from another outreach tool, or one sentence. Follow these steps in\norder. Only step 3 (search), step 6 (AI lines) and step 9 (launch) spend money\nor send messages; say so before each one and wait for a yes before step 9.\n\n### 0. Check the prerequisites\n\n- **Campaign commands available.** Run `dench campaign help` and confirm it\n lists `draft`, `search`, `add`, `steps`, `person` and `preview`. An older CLI\n answers \"Unknown campaign subcommand: search\". Update with `npm install -g @dench.com/cli@latest`,\n or run commands as `npx -y -p @dench.com/cli@latest dench …`. The CLI comes\n preinstalled in a Dench chat sandbox. When testing a source checkout, check\n its campaign help: commands can be available before a release version bump.\n- **A workspace member's credentials.** `dench signin` (the human approves a\n link), a member-bound `DENCH_API_KEY`, or an agent session a member created.\n An organization-only key is refused with \"Outreach needs a workspace\n member's credentials\". Check with `dench context --json`.\n- **A paid workspace with credits.** Search and AI lines are billed to the\n workspace. `dench billing status --json` shows the balance; `dench upgrade`\n and `dench billing topup --amount 10` give the human a link.\n- **Connected senders.** `dench campaign accounts --json` must list a mailbox\n (for email steps) and/or a LinkedIn account (for LinkedIn steps). If a\n channel is empty, `dench tool connect gmail` (or `outlook`, `linkedin`)\n prints a sign-in link; the human opens it, then run `dench campaign\n accounts` again. Ids from this command go into `--email-mailboxes` and\n `--linkedin-accounts`.\n\n### 1. Turn the brief into a plan\n\nPull these out of the brief and ask the user only for what is missing:\n\n| Need | Where it goes |\n|---|---|\n| Who to reach: titles, seniority, industries, company size, places | search filters (step 3) |\n| Who to leave out: competitors, dev shops, current clients, wrong industries | exclusions (step 3) |\n| How many people | one campaign holds at most 300 (step 4) |\n| Channels and timing: which touches, how many days apart | `steps.json` (step 7) |\n| Branches: \"if they're connected…\", \"if they don't accept…\", \"if their title contains…\" | a workflow `steps.json` (step 7) |\n| What changes per person: first name, company, a role or reason to write | variables (steps 5 and 6) |\n| Timezone, days and hours, daily email cap, which accounts send | the draft (step 2) |\n| Buying signals (hiring, funding, launches, new leaders, post engagement) | the signal builder, below, instead of steps 3 and 4 |\n\nFilter names, exact values and ranges: `dench leads filters` (free) lists\nthem, `dench leads filters --filter industries --search \"financial\"` finds an\nexact industry name. Company size is a headcount bucket (`1-10`, `11-50`,\n`51-200`, `201-500`, `501-1000`, `1001-5000`, `5001-10000`, `10001+`); there is\nno revenue filter.\n\n### 2. Create the draft\n\n```bash\ndench campaign draft --name \"Fintech engineering leaders\" \\\n --request-id fintech-eng-leaders-q4 --timezone America/New_York \\\n --window \"Mon-Fri 9-17\" --daily-cap 30 \\\n --email-mailboxes <mailboxId> --linkedin-accounts <linkedinAccountId> --json\n```\n\n`--request-id` (8-64 characters) makes a retry return the same draft instead of\na second one. Without sender flags the draft sends from every running account\nyou own; the output says which. A draft sends nothing.\n\n### 3. Search, with exclusions\n\n```bash\ncat > filters.json <<'EOF'\n{\n \"titles\": [\"CTO\", \"VP Engineering\", \"Head of Engineering\"],\n \"industries\": [\"Financial Services\", \"Hospitals and Health Care\"],\n \"headcountRanges\": [\"51-200\", \"201-500\", \"501-1000\"],\n \"locations\": [\"United States\"]\n}\nEOF\n\ndench campaign search --filters @filters.json \\\n --not-industries \"IT Services and IT Consulting,Staffing and Recruiting\" \\\n --not-company-keywords \"software outsourcing\" \\\n --not-domains competitor.com,current-client.com \\\n --limit 25 --out audience.json\n```\n\n- **Cost: 1 cent per person returned**, billed on what comes back, not on the\n limit. The most a call can cost prints on stderr before it runs, and the\n result carries `estimatedCents` and `chargedCents`. There is no free preview;\n start with `--limit 25`, read the sample, then widen.\n- **Exclusions.** `--not-<filter>` (or `--exclude-<filter>`) works on every list\n filter, for example `--not-industries`, `--not-titles`, `--not-company-names`,\n `--not-company-keywords`; `--not-domains` is short for `--not-company-domains`.\n In JSON an exclusion is `{\"value\":\"Staffing and Recruiting\",\"exclude\":true}`\n inside that filter's list. A search still needs at least one include filter.\n- `--limit` is at most 100 per search. Continue with `--page-token\n <nextPageToken>` from the previous result (even after an empty page); keep the\n same filters.\n- `--out audience.json` writes the full result, complete profiles included, and\n the terminal shows a short summary. `--raw` prints the full result instead of\n writing a file. The file is checked before the search is billed: its folder\n must exist and the file must not (`--force` replaces it), so give each page\n its own name (`audience-2.json`). If the write still fails, the result prints\n on stdout with a `saveError` instead of being lost; do not run the search\n again.\n- Review before adding: `jq -r '.rows[] | [.name,.title,.company] | @tsv'\n audience.json`. Show the user 5-10 people and the cost so far. If the sample is\n wrong, change the filters and search again (each search is billed).\n\n### 4. Add the people\n\n```bash\ndench campaign add \"Fintech engineering leaders\" --people-file audience.json\n```\n\nThis adds the searched people without searching or paying again, up to 300\npeople per file, in batches of 20. New people become Leads in the CRM. The\nresult lists `added`, `duplicates`, `duplicatesElsewhere` (already queued or\nenrolled in another campaign, skipped unless `--allow-duplicates`), `suppressed`,\n`invalid`, `skippedNoIdentity`, `skippedMissingInfo` and `cappedAtLimit`. Read\nit back to the user.\n\nOther ways in, all with the same checks: `add --search '<filters json>'\n--limit 50` (search and add one page in a single billed call), `add --csv\npeople.csv`, `add --list <artifactId>`, `add --object lead --view \"<view>\"`,\n`add --name \"Ada\" --email ada@x.com`. See Add people below.\n\n- **A campaign holds 300 people**, counting stopped and finished ones. For a\n bigger audience, `dench campaign duplicate <campaign>` makes a new draft with\n the same steps, schedule, senders and lines and no people; add the next page\n of the search to the copy (`search --page-token …`). Duplicate checks include\n draft, active and paused campaigns, so someone queued or enrolled elsewhere\n is skipped.\n- People need an email for email steps and a LinkedIn profile URL for LinkedIn\n steps. A person without an email has their email steps skipped (launch warns);\n someone with neither is a launch blocker. Search results carry a LinkedIn URL\n and, when available, an email.\n- A mistake in a draft: `dench campaign remove <campaign> --person\n <enrollmentId|name>` takes a never-contacted person out and frees their place.\n\n### 5. Choose the variables\n\nA `{{token}}` or `[[token]]` in a subject or message is filled in per person.\nBoth forms work in email and LinkedIn messages, InMail subjects, previews and\nsends. Typing either opener brings up field suggestions, and choosing a field\nkeeps the brackets you started with:\n\n- **Fields of the person or their CRM row:** `{{First name}}`, `{{Company}}`,\n `{{Job Title}}`, `{{Website}}`, `{{Location}}` and any other column of the\n record.\n- **Values you supply.** In a `--people-file`, put them under `personalization`\n for each person: `{\"linkedinProfileUrl\":\"…\",\"personalization\":{\"fund\":\"Seed\n fund\",\"role_title\":\"Head of Data\"}}` makes `{{fund}}` and `{{role_title}}`. In\n a CSV every column that is not an email, LinkedIn URL or name becomes a value\n named after its header.\n- **Greeting names.** Built-in `name`, `firstName` and `lastName` are cleaned\n for greetings, so casing and credentials may change. Custom keys such as\n `first_name`, `Fund` and `role_title` keep the values you supply. To confirm\n an exact built-in name, use `dench campaign person set <campaign> --person\n <name> --field \"name=Hortensia Ruiz, MBA\"`.\n- **Fallbacks.** `{{First name || \"there\"}}` or `[[First name || \"there\"]]`.\n A plain token with no value for\n someone is a **launch blocker** for that person; a quoted fallback avoids it.\n Fix a single person before launch with `dench campaign person set\n <campaign> --person <name> --field \"Company=Acme\"`, or pull missing fields\n from their CRM record with `dench campaign sync <campaign>`.\n- **Brackets.** Write `{{First name}}` or `[[First name]]`, with a matching\n pair of double braces or square brackets. `steps set` refuses\n `{first_name}` or `{FIRST_NAME}`, which would go out exactly as typed; pass\n `--allow-single-braces` only when the braces are literal text.\n\n### 6. Optional: AI-written lines\n\nFor a line that must differ for every person (a reason to write, a comment on\ntheir company), define up to 5 AI-written lines. They cost about 3 cents a\nperson; say so, then:\n\n```bash\ncat > lines.json <<'EOF'\n{\n \"sells\": \"Senior engineers who join your team or own a build end to end\",\n \"lines\": [\n {\n \"label\": \"Why now\",\n \"instructions\": \"One sentence tying their company's business to engineering capacity.\",\n \"fallback\": \"building the roadmap faster\"\n }\n ]\n}\nEOF\ndench campaign personalize set \"Fintech engineering leaders\" --file lines.json\ndench campaign personalize get \"Fintech engineering leaders\"\n```\n\nUse the line in steps as `{{whyNow}}` (the key is made from the label; `get`\nprints it). Saving writes lines for up to 100 people right away; more waits\nfor `personalize write --yes`. Edit one person's line with `personalize edit`,\nredo it with `personalize rewrite`. Until a line is written the saved fallback\nis used and it never blocks launch.\n\n### 7. Write and check the steps\n\nFirst decide the shape. If everyone gets the same touches in the same order,\n`steps.json` is a plain JSON array in send order. If the brief says \"if …,\nthen …\" (connected or not, accepted or not, has an email or not, a field's\nvalue), it is a workflow: `{\"stepModel\":\"workflow\",\"steps\":[...]}` with\npaths (see Workflows below). Each step is one of `email`, `wait`,\n`linkedin_visit`, `linkedin_connection`, `linkedin_message`,\n`linkedin_like_post` or `linkedin_inmail`; a workflow can also use\n`condition` (If / else) and `wait_for_connection` (Wait for them to accept).\nTiming is a `wait` step between the\ntouches: wait hours = (day of this touch − day of the\nprevious touch) × 24. This example turns \"email day 1, LinkedIn connect day 2,\nLinkedIn message day 4 after they accept, email day 5 in the same thread,\nLinkedIn bump day 8, email day 10 in the same thread\" into steps:\n\n```json\n[\n {\n \"type\": \"email\",\n \"emailSubject\": \"Keep building while you hire\",\n \"emailTextBody\": \"{{First name || \\\"Hi\\\"}}, saw {{Company}} is hiring for {{role_title || \\\"engineering\\\"}}. We add senior engineers to your team or own a build end to end.\\n\\nWant me to send a few profiles?\"\n },\n { \"type\": \"wait\", \"waitHours\": 24 },\n {\n \"type\": \"linkedin_connection\",\n \"linkedinMessageBody\": \"{{First name || \\\"Hi\\\"}}, saw {{Company}} is hiring. We add senior engineers to your team on your hours. Open to connecting?\"\n },\n { \"type\": \"wait\", \"waitHours\": 48 },\n {\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Thanks for connecting, {{First name || \\\"there\\\"}}. Want me to send a few profiles that match your open roles?\",\n \"linkedinMessageMode\": \"wait_until_connected\",\n \"connectionTimeoutHours\": 336\n },\n { \"type\": \"wait\", \"waitHours\": 24 },\n {\n \"type\": \"email\",\n \"emailReplyToPrevious\": true,\n \"emailTextBody\": \"Following up on the {{role_title || \\\"engineering\\\"}} role. Can we find 15 minutes this week?\"\n },\n { \"type\": \"wait\", \"waitHours\": 72 },\n {\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Circling back, {{First name || \\\"there\\\"}}: worth 15 minutes this week?\",\n \"linkedinMessageMode\": \"skip_if_not_connected\"\n },\n { \"type\": \"wait\", \"waitHours\": 48 },\n {\n \"type\": \"email\",\n \"emailReplyToPrevious\": true,\n \"emailTextBody\": \"Last note from me. Want me to send a few profiles?\"\n }\n]\n```\n\n```bash\ndench campaign steps set \"Fintech engineering leaders\" --file steps.json\ndench campaign preview \"Fintech engineering leaders\" --person \"Ada Lovelace\"\n```\n\n`steps set` validates before it saves and refuses anything that would be\nsilently dropped or sent wrong (rules in Steps below). `preview` shows the exact\nmessages one person would get, with every token and AI line filled in, and\nsays what is missing or would be skipped; nothing is sent. Preview two or\nthree different people and show the user the text. In a workflow, `preview`\nshows the message of every path, and a person gets only the ones on the path\nthey take: say which path each message is on, or preview one with `--step N`.\n\nPost reactions, InMail and scheduled withdrawal of pending invitations are\nsupported; see the Steps section for their fields and limits. A plain list\nlike the one above runs every step in order for everyone; `onlyIf` on email\nand post-like steps and `linkedinMessageMode` adjust it to whether someone\nis connected. When the brief branches (\"if they are connected, message them;\nif not, send a connection request, wait 10 days for the accept and InMail the\nones who don't accept\"), write a workflow instead (Workflows under Steps):\neach step gets a `key` and says where it goes, and If / else (`condition`)\nand Wait for them to accept (`wait_for_connection`) steps choose the path.\nBefore saving, tell the user how you mapped the brief: each \"if\" and the\nstep that answers it, where the paths join again, where each one ends, and\nanything you changed because a workflow can't do it (a path that goes back\nto an earlier step, more than 20 steps). Dench also checks whether someone\nis already connected before sending an invitation.\n\n### 8. Check readiness\n\n```bash\ndench campaign launch \"Fintech engineering leaders\" --check --json\n```\n\n`--check` never launches. It lists each blocker with why it fires and the\ncommands that fix it, the warnings, the audience and step counts and the\n`fingerprint`, and exits 1 when blocked. Fix blockers (`steps set`, `add`,\n`remove`, `person set`, `set`) and run it again until it exits 0.\n\nThen show the user, in one message: the number of people and five examples, the\nsteps as rendered by `preview`, the schedule and timezone, the daily email cap,\nthe sending accounts, what has been spent, and that LinkedIn steps break\nLinkedIn's terms and can get the account restricted. Ask for a clear yes.\n\n### 9. Launch and watch\n\n```bash\ndench campaign launch \"Fintech engineering leaders\" --ack-linkedin-risk\ndench campaign get \"Fintech engineering leaders\"\ndench campaign replies \"Fintech engineering leaders\" --since 7d\n```\n\n`--ack-linkedin-risk` is required only when the campaign has LinkedIn steps and\nonly after the user accepts the notice. `launch` without `--check` launches as\nsoon as the campaign is ready. After launch:\n\n- `get` is the dashboard: funnel, what is sending now, what comes next and\n why anything is holding (hold reasons clear on their own; report the hold,\n not a failure). `events` is the activity log; `people --status replied` lists\n who answered; `replies` shows what they wrote; `pipeline` shows where people\n sit in the lead pipeline.\n- Change wording or waits in place with `steps edit`; stop a person with `stop`;\n `pause` and `resume` the whole campaign.\n- Replying to a prospect happens in the Inbox in the Dench app.\n\n### Fixing mistakes\n\n| Mistake | Fix |\n|---|---|\n| Added the wrong person (draft) | `dench campaign remove <c> --person <id>` |\n| Wrong email or LinkedIn URL (draft) | `dench campaign person set <c> --person <id> --email … --linkedin-url …` |\n| Typo in a message after launch | `dench campaign steps edit <c> --file steps.json` |\n| Step types, order or a workflow's paths must change after launch | `steps edit` keeps them fixed. `dench campaign duplicate <c>`, fix the copy, and add only people who were never contacted to it |\n| Person should stop getting messages | `dench campaign stop <c> --person <id>` |\n| Whole campaign is wrong | `dench campaign pause <c>`, or `archive` / `delete` (same thing: stops everyone, erases nothing) |\n| A search was too broad | Nothing refunds a search; narrow the filters, and check `estimatedCents` first |\n\n## The New campaign flow (all five sources)\n\nThe app's **New campaign** page starts by asking where people come from. Each\nanswer to question 1 maps to commands:\n\n| Source | What it is | Commands |\n|---|---|---|\n| **Signals** | People showing buying intent, found again on a schedule | `builder save` (`\"source\":\"signals\"`) → `build` → `get` → `sequence`/`outreach` → `create` |\n| **Lookalike** | People like one best lead, found again on a schedule | `builder lookalike` → `save` (`\"source\":\"lookalike\"`, `\"signals\":[\"lookalike\"]`, `lookalike`) → the same as Signals |\n| **Existing leads** | A pasted list or a CSV | `draft` → `add --csv` / `--people-file` / `--name … --email …` (steps 2 and 4 above) |\n| **From CRM** | Records already in the CRM | `draft` → `add --object lead --view \"<view>\"` or `--entries` (Add people below) |\n| **Find new people** | A one-time filtered search | `draft` → `search` → `add --people-file` (steps 2-4 above) |\n\nSignals and Lookalike keep finding people after launch. The other three are a\nfixed list.\n\n### Signals and Lookalike, step by step\n\n```bash\ndench campaign builder profile --json # recommendations (free)\ndench campaign builder autofill --description \"VP Sales at US SaaS companies\" --json # optional: words -> targeting\ndench campaign builder estimate --data '{\"kind\":\"week\",\"targeting\":{...},\"signals\":[\"post_engagement\"],\"signalTerms\":{...}}' --json\ndench campaign builder save --file draft.json --json # -> draftId; nothing billed yet\ndench campaign builder build <draftId> --json # billable: finds the first people, writes openers\ndench campaign builder get <draftId> --json # poll until status is ready; review people and openers\ndench campaign builder opener <draftId> <leadId> --text \"...\" --json # fix an opener (\"\" resets it)\ndench campaign builder sequence <draftId> --goal \"Book a demo\" --help-with \"...\" --tone conversational --channels both --json\ndench campaign builder outreach <draftId> --file outreach.json --approval manual --json\ndench campaign builder create <draftId> --name \"...\" [--paused] --json # makes the campaign; does not launch\n```\n\nThen check readiness and launch as in steps 8 and 9 above. `create --paused`\nis the app's \"Save paused\": signals wait to run until launch.\n\n**`draft.json`** (every field the app saves):\n\n```json\n{\n \"clientRequestId\": \"ai-sales-leaders-2026-10\",\n \"name\": \"AI-curious sales leaders\",\n \"source\": \"signals\",\n \"targeting\": {\n \"titles\": [\"VP Sales\", \"Head of Sales\", \"CRO\"],\n \"industries\": [\"Software Development\"],\n \"companySizes\": [\"51-200\", \"201-500\"],\n \"locations\": [\"United States\"],\n \"excludes\": [\"competitor.com\"],\n \"companyTypes\": [\"Startup\"]\n },\n \"signals\": [\"post_engagement\", \"hiring\", \"funding\"],\n \"signalTerms\": {\n \"post_engagement\": [\"using AI for outbound\", \"AI SDR results\"],\n \"hiring\": [\"SDR\", \"Sales Development Representative\"]\n },\n \"findMoreMatching\": false\n}\n```\n\n- **Signals**: `post_engagement` (people who post or comment on a topic),\n `keyword` (posts mentioning a keyword), `hiring` (companies hiring a role),\n `funding`, `launch`, `new_leader`, `voice_engagement` (people engaging with\n chosen LinkedIn experts; terms are profile URLs, suggested by `builder voices\n --topics \"...\"`), `company_engagement` (people engaging with a company's or a\n competitor's page; terms are company page URLs), `brand_engagement` (people\n engaging with your own company page), and `lookalike` (Lookalike source\n only).\n- **Topics** (`post_engagement`, `keyword`): write what the buyer does or\n wants, not a bare product or brand name. Dench reads each topic for its\n meaning and searches for posts about that meaning, so \"Claude for GTM\" means\n sales teams using AI for sales, never posts that only mention Claude. A topic\n in `\"exact\": [\"keyword\"]` is searched as typed and the post must contain it.\n- **`findMoreMatching: true`** also adds people who match the audience without\n a signal.\n- **Lookalike**: `builder lookalike --linkedin-url <url>` returns the seed and\n an editable setup (role, `similarRoles`, `roles`, location, industry,\n `relatedIndustries`, `industries`, `companySizes`, similar `companies`).\n Show it to the user, apply their edits, and pass it as `lookalike` in\n `draft.json`. `--data '{\"suggest\":{\"title\":\"…\"}}'` suggests roles again;\n `--data '{\"rescope\":{\"seed\":{…},\"company\":\"…\"}}'` switches the company.\n\n**`outreach.json`** (the app's Outreach and Review screens):\n\n```json\n{\n \"brief\": {\"goal\": \"Book a demo\", \"helpWith\": \"...\", \"tone\": \"conversational\", \"channels\": \"both\"},\n \"steps\": [{\"type\": \"linkedin_connection\"}, {\"type\": \"wait\", \"waitHours\": 48}, {\"type\": \"email\", \"emailSubject\": \"...\", \"emailTextBody\": \"...\"}],\n \"sending\": {\"emailMailboxAccountIds\": [\"...\"], \"linkedinAccountIds\": [\"...\"], \"timezone\": \"America/New_York\",\n \"startHour\": 9, \"endHour\": 17, \"weekdays\": [1,2,3,4,5], \"dailySendCap\": 30},\n \"approvalMode\": \"manual\"\n}\n```\n\n`builder sequence` writes `steps` from the brief, as **Generate sequence**\ndoes (AI credits apply). Leave `steps` out of `outreach.json` after it, or use\n`--mode manual` with your own steps. In `weekdays`, 0 is Sunday.\n`approvalMode` `manual` (the default) holds each new person a signal finds\nuntil someone approves them. `auto` starts them on their own.\n\n**Drafts**: every save is resumable. `builder drafts` lists unfinished ones,\n`builder resume <draftId>` shows a draft's setup, `builder discard <draftId>`\ndrops it. `save` with the same `clientRequestId` updates the same draft. A\nsave without `screen` reopens on `target` (`lookalike` for a lookalike).\n`targeting` and `signalTerms` take only the keys shown above: an unknown key\n(`seniorities`, `companyHeadquarters`, …) is refused, not dropped.\n\n### A live signal campaign (the Sources tab)\n\n```bash\ndench campaign sources overview \"<campaign>\" --json # each signal: status, last/next run, people found, problems\ndench campaign sources run \"<campaign>\" --json # Run now (billable; 6 an hour; live campaigns only)\ndench campaign sources pending \"<campaign>\" --json # people waiting for approval\ndench campaign sources approve \"<campaign>\" --people <enrollmentId,...>\ndench campaign sources reject \"<campaign>\" --people <enrollmentId,...>\ndench campaign sources set \"<campaign>\" --approval auto\ndench campaign sources set \"<campaign>\" --data '{\"cadence\":\"weekly\"}'\ndench campaign sources set \"<campaign>\" --data '{\"signal\":{\"signal\":\"hiring\",\"enabled\":false}}'\ndench campaign sources set \"<campaign>\" --data '{\"terms\":{\"signal\":\"post_engagement\",\"values\":[\"using AI for outbound\"]}}'\ndench campaign sources preview \"<campaign>\" --signal hiring --json # sample results; enrolls no one\ndench campaign queue \"<campaign>\" --json # who goes out today, warmest first\n```\n\n- Each run continues where the last one stopped and skips people already in\n the campaign, so a quiet day means nothing new was posted, not a broken\n signal. `Run now` is for testing a change right away.\n- `sources set` takes one change per call: `status` (`active`/`paused`),\n `cadence` (`daily`/`weekly`/`monthly`), `findMoreMatching`, `approvalMode`,\n `targeting`, one `signal` on or off, or one signal's `terms`.\n- **Intent** (the bars next to each person on the Leads tab): High, Medium\n or Low. It weighs fit with the campaign's target titles and\n buyer profile first, then the signal. Someone outside the target titles is\n Low however strong their post. Warmer people go first in today's queue.\n Someone whose title is a different job altogether (HR commenting on a\n sales post; not just another word or level for a target title) is Low\n whatever they posted, and a signal lead like that is removed before\n anything is sent; the source won't add them again. Changing the target titles\n re-rates everyone in the campaign.\n\n## Commands\n\n`<campaign>` is a campaign **id or its exact name** (case-insensitive). When\ntwo live campaigns share a name the command fails and lists both ids; use the\nid. `dench campaign list` shows ids.\n\n### Browse and inspect\n\n```bash\ndench campaign list [--all] [--json] # live campaigns; --all includes archived\ndench campaign get <campaign> [--json] # status, schedule, funnel, Now/Next, holds, people\ndench campaign people <campaign> [--status <s>] [--json]\ndench campaign events <campaign> [--limit 50] [--max-pages 1] [--json]\ndench campaign accounts [--json] # email + LinkedIn sender ids, warm-up, availability and capacity\ndench campaign preview <campaign> [--person <enrollmentId|name>] [--step N] [--json]\ndench campaign person show <campaign> --person <enrollmentId|name> [--json]\ndench campaign replies <campaign> [--person <enrollmentId|name>] [--since 7d] [--limit 20] [--json]\ndench campaign pipeline <campaign> [--json]\ndench campaign where <entryId> [--json]\n```\n\n`people --status` accepts an enrollment status: `draft` (not launched yet),\n`active`, `paused`, `finished` (reached the end: every step of a plain list, or\nthe end of their path in a workflow), `replied`, `stopped`,\n`bounced`, `complained`, `unsubscribed`, `failed`.\n\n`events` is the campaign's activity log, newest first: added, launched,\nemail sent, connection request sent, accepted the connection, LinkedIn\nmessage sent, profile visited, replied, step skipped, step failed, needs a\nlook, paused, resumed, stopped, finished, bounced, unsubscribed, campaign\ncompleted, campaign picked back up, campaign archived. `--limit` is the page size (1-200);\n`--max-pages` drains more pages. `--json` returns `{ events, isDone,\ncontinueCursor }`.\n\n`preview` renders every email and LinkedIn step (or step N) for one person\n(the first person when `--person` is left out) with fields and AI lines filled\nin. In a workflow that is every path's messages; the person gets only the ones\non their path. `person show` lists each step a person reached with its outcome (sent,\nopened, clicked, skipped and why, waiting, failed), when, and the subject and\nstart of the text that was sent. `replies` lists the people who replied, newest\nfirst, with the text of their latest inbound email or LinkedIn message (up to\n400 characters, quoted history removed) and whether you have answered.\n`pipeline` counts a campaign's people at each lead Status. `where <entryId>`\nlists the campaigns a CRM person or lead is in and their status in each.\n\n### Create and configure\n\n```bash\ndench campaign create --name \"<name>\" [--timezone <IANA tz>] \\\n [--window \"<spec>\" ...] [--daily-cap 1-100] [--stop-on-reply|--no-stop-on-reply] \\\n [--email-mailboxes id1,id2] [--linkedin-accounts id1,id2] \\\n [--start <ISO date/time>] [--end <ISO date/time>] [--json]\n\ndench campaign draft [--name \"<name>\"] [--request-id <8-64 chars>] [same settings as create] [--json]\n\ndench campaign set <campaign> [--name \"<new name>\"] [--timezone <tz>] [--window \"<spec>\" ...] \\\n [--daily-cap 1-100] [--stop-on-reply|--no-stop-on-reply] \\\n [--email-mailboxes id1,id2|none] [--linkedin-accounts id1,id2|none] \\\n [--start <ISO>|--clear-start] [--end <ISO>|--clear-end] [--json]\n\ndench campaign duplicate <campaign> [--name \"<name>\"] [--json]\ndench campaign archive <campaign> [--json] # stops everyone still in flight; final\ndench campaign delete <campaign> [--json] # the same command, named like Delete in the app\n```\n\n`create` and `draft` make the same kind of draft; `draft` is the retry-safe\none (a stable `--request-id`) and the name is optional.\n\n- `--timezone` defaults to the machine's timezone (UTC in a sandbox — pass\n the user's zone). With no `--window`, the campaign gets one window:\n Mon-Fri 9-18 in that timezone.\n- `--daily-cap` is the number of cold emails per day across the campaign\n (default 30, max 100). LinkedIn has its own per-account limits, set on the\n account, not here.\n- `--email-mailboxes` and `--linkedin-accounts` select **sender pools on the\n campaign**, not on individual steps. Each accepts up to 50 account ids,\n comma-separated or as a JSON array. Only accounts both the caller and the\n campaign owner may use are accepted; `create` and `draft` check them as the\n campaign is created, so a sender that can't be used creates nothing. If a\n later setting fails to save, the error names the campaign that was created\n (with `draft`, re-run with the same `--request-id` to update it). The app\n puts these under **Settings → Sender pools**, with remaining-today counts and\n availability.\n- Omit a sender flag to preserve that channel's current configuration. Pass\n `none` or `'[]'` to clear it. Legacy per-step senders remain until that\n channel's pool is explicitly configured. Each person's assigned sender\n stays fixed through their conversation, including after a pool is changed;\n disconnecting it does not silently move the conversation to another sender.\n- API equivalents: `emailMailboxAccountIds` and `linkedinAccountIds` on\n `POST /campaigns` and `PATCH /campaigns/{sequenceId}`. Launch readiness\n checks remain mandatory; selecting a sender does not bypass them.\n- `--stop-on-reply` (the default) stops a person's remaining steps the\n moment they reply on either channel. `--no-stop-on-reply` keeps sending.\n- `--start` / `--end` bound the campaign in time (ISO 8601). A bare date\n (`2026-09-03`) is midnight at the start of that day in the campaign's\n timezone (`--timezone`, or the campaign's own), so `--end 2026-10-01`\n means \"nothing goes out on or after Oct 1 local time\". A time without an\n offset (`2026-09-03T09:00`) is that time in the same campaign timezone,\n never the timezone of the machine running the CLI; add an offset\n (`2026-09-03T09:00:00-07:00`) to pin the instant. Impossible dates such as\n `2026-02-30` and non-ISO formats are refused. `--clear-start` /\n `--clear-end` remove them.\n- `set` works for the life of the campaign (not once archived). Steps are\n the one thing `set` does not cover; see Steps below.\n- `set --timezone X` alone moves the existing windows to that zone.\n- `duplicate` makes a new draft named \"<name> copy\" (or `--name`) with the same\n steps, schedule, sender pools and AI lines, and no people.\n- `archive` and `delete` stop everyone still in flight and keep every lead and\n all activity; a campaign is never erased.\n\n#### `--window` spec\n\n`\"<days> <start>-<end>\"`, repeatable (up to eight), all in `--timezone`:\n\n| Spec | Meaning |\n|---|---|\n| `\"Mon-Fri 9-18\"` | weekdays, 09:00 until 18:00 |\n| `\"Mon,Wed,Fri 10-16\"` | those three days |\n| `\"Weekdays 9am-5pm\"` | am/pm accepted; `Weekdays`, `Weekends`, `Daily` are groups |\n| `\"Sat-Sun 10-14\"` | day ranges wrap (`Fri-Mon` = Fri, Sat, Sun, Mon) |\n\nHours are whole hours, 0-24; the end must be after the start. Minutes are\nnot supported.\n\n### Add people\n\n```bash\n# search filters: the flags, or --search/--filters JSON (same object, @file.json works)\ndench campaign search --filters @filters.json [--titles Founder,CEO] [--not-industries \"Staffing and Recruiting\"] [--limit 100] [--page-token <t>] [--out audience.json] [--raw]\ndench campaign add <campaign> --search '{\"titles\":[\"Founder\"],\"locations\":[\"United States\"]}' [--limit 50] [--page-token <t>] [--preview] [--allow-active] [--allow-duplicates] [--out added.json]\ndench campaign add <campaign> --titles Founder --locations \"United States\" [--headcount 11-50] [--not-domains example.com] [--limit 50]\n\n# people you already have\ndench campaign add <campaign> --people-file audience.json [--allow-duplicates]\ndench campaign add <campaign> --csv people.csv [--map \"email=Work Email\" ...] [--preview] [--allow-duplicates]\ndench campaign add <campaign> --list <artifactId> [--limit 100] [--enrichment enriched] [--preview] [--allow-duplicates]\n\n# CRM records\ndench campaign add <campaign> --object lead --view \"Q3 targets\" [--email-field Email] [--linkedin-field \"POC LinkedIn URL\"] [--name-field Name] [--allow-duplicates] [--json]\ndench campaign add <campaign> --object people --entries <id1>,<id2> [--relation-field Contact] [--reverse] [--json]\n\n# one person with no CRM row yet (a lead is created); needs --email, --linkedin-url or both\ndench campaign add <campaign> [--name \"Ada Lovelace\"] --email ada@example.com [--linkedin-url https://linkedin.com/in/ada] [--json]\n```\n\n**Search and filters.** `--filters` and `--search` take the same JSON with every\npeople filter and work on both `search` and `add`. The flags `--titles`,\n`--past-titles`, `--person-names`, `--locations`, `--seniorities`,\n`--past-seniorities`, `--profile-keywords`, `--company-keywords`,\n`--industries`, `--functions`, `--sub-functions`, `--company-domains`,\n`--company-names`, `--past-company-names`, `--company-hq`, `--company-types`,\n`--universities`, `--skills`, `--languages`, `--headcount`, the ranges\n`--years-in-role`, `--years-at-company`, `--days-since-job-change`,\n`--founded-years` (`min:max`), and `--exact` add to that JSON: list flags\nappend to the JSON lists, so exclusions in the JSON survive. `--not-<flag>` and\n`--exclude-<flag>` leave values out of any list filter. A filter name that is\nnot allowed lists the allowed ones and the nearest match. `dench leads filters`\nprints accepted values.\n\nA flag value is split at its commas: `--titles \"CTO,VP Engineering\"` is two\ntitles, and a Note on stderr shows how a value was split (not for domains or\nexact filter values such as seniorities). Names with a comma that match a known\nvalue stay whole (the industry \"Technology, Information and Internet\"). A\ntitle, place or company name that contains a comma must be wrapped in double\nquotes inside the shell quotes, `--titles '\"Vice President, Information\nSystems\"'` or `--not-company-names '\"Acme, Inc.\"'`, or go in the `--filters`\nJSON. Otherwise it becomes several values and widens a billed search.\n\n**Limits and cost.** `search` returns at most 100 people per call and `add\n--search` adds at most 50 (a higher `--limit` is capped, with a note). Search\nand `--preview` cost 1 cent per person returned; `add --search --preview` means\n**no enrollment**, not a free search. Adding with `--people-file`, `--csv`,\n`--list`, `--object` or a single person is free of search cost. Adding with a\nsearch into a campaign that is already active, paused or completed needs\n`--allow-active`, because new people start its steps right away. Every add\nresult carries `campaignStatus`.\n\n**`--people-file`** accepts a recipient array or the result of `campaign search`\n(its `recipients`), 1-300 people. A recipient may contain `email`,\n`linkedinProfileUrl` (also `linkedinUrl`, `linkedin`), `displayName` (also\n`name`, `fullName`) and `personalization` (merge values); other text columns\nbecome merge values named after the key. An unknown value type is refused with\nthe row number instead of being dropped. New identities become Leads.\n`--allow-duplicates` only disables the cross-campaign duplicate check, not\nsuppression or campaign-local deduplication.\n\n**`--csv`** reads a spreadsheet export the way the app's Add people does: the\nemail and LinkedIn columns are found from what they hold, whatever they are\ncalled; the name comes from First name + Last name columns or from one `Name`,\n`Full name` or `Contact` column, found by its header (that column also stays\navailable as a merge value); every other column becomes a merge value\n(`{{Company}}`, `{{Job Title}}`). `--map\nemail|linkedin|name|first|last=\"<header or column letter>\"` overrides a guess\n(`none` switches a field off); `name` is the whole name in one column and cannot\nbe combined with `first` or `last`. `--preview` shows how each column is read\nand adds nobody, and the `Read` note says when no name column was found. Comma,\nsemicolon and tab files work, up to 5 MB and 500 people.\n\n**`--list`** adds people from a saved list (`dench lists`, made by `dench leads\nfind --save-as`) without searching or paying again. New people become Leads\nduring enrollment, in batches of 20. Custom values saved under each person's\n`personalization` object are preserved, including `role_title` and `Fund`.\n`--enrichment` keeps only rows at that stage\n(`all`, `enriched`, `in_progress`, `no_contacts`, `failed`, `not_enriched`).\n`--limit` is how many people to add (up to the campaign's room, 300 at most;\na lower effective limit is reported as `limitClamped`). Rows already in the\ncampaign are skipped and later rows take their places, so running the same\ncommand again reaches the rest of the list.\n\n**CRM records.**\n\n- One person needs at least one of `--email` / `--linkedin-url`. `--name`\n is only for this form; with `--object`, pick the name column with\n `--name-field`.\n- A campaign holds at most **300 people**. `add` stops at the cap and says\n so (`cappedAtLimit`). Adding works on drafts and on launched campaigns\n (new people start at step 1); not on archived ones.\n- `--view` reads the saved view's own filters, sort and pinned rows, the\n same rows `dench crm views entries <object> \"<view>\"` returns. A view\n over more than 1000 rows cannot be listed fully (`truncated`); the\n command warns and only the listed rows are considered — narrow the view.\n- Each record needs an email (`--email-field`, default the `Email`\n column) and/or a LinkedIn profile URL (`--linkedin-field`, default the\n LinkedIn URL column). Records with neither are skipped\n (`skippedNoIdentity`). `--relation-field Contact` follows a relation to\n the person record first; `--reverse` walks it the other way.\n- By default a person already **queued or enrolled in another draft, active or\n paused campaign** is skipped (`duplicatesElsewhere`); `--allow-duplicates`\n adds them anyway. Remove them from one draft's audience, archive an old draft,\n or stop their enrollment in a launched campaign to resolve the conflict.\n Someone already in this campaign is never added twice (`duplicates`; `merged`\n counts the ones that gained a missing email or URL). Unsubscribed or\n bounced people are skipped (`suppressed`).\n- The result says how many were added and why the rest were not. Read it\n back to the user before launching.\n\nEvery enrolled person **gets a lead**: a `lead` row is used as-is; a\n`people` row finds the lead whose `Contact` is that person or creates one\n(`Status = New`, `Source = Outbound`, `Contact` linked); a bare `--email` /\n`--linkedin-url` creates the lead too. Workspaces without a `lead` object\nstamp the person instead.\n\n### Steps\n\n```bash\ndench campaign steps get <campaign> [--with-ids] # JSON you can edit and save: an array, or {\"stepModel\":\"workflow\",\"steps\":[...]} for a workflow\ndench campaign steps set <campaign> --file steps.json [--allow-single-braces] [--json] # replaces every step; DRAFTS ONLY\ndench campaign steps edit <campaign> --file steps.json [--allow-single-braces] [--json] # text and waits in place, also after launch\n```\n\n`steps set` replaces every step and works only while the campaign is a draft.\n`steps edit` keeps the number, order and type of every step and changes their\ntext, waits, reactions, withdrawal settings and conditions, also after launch (people already waiting keep the\ntiming they started with; messages already sent, or already being prepared, keep\ntheir text). In `steps edit` each step in the file is its full new content:\nleaving out a subject (including `inmailSubject`), body, note, `onlyIf` or\n`emailReplyToPrevious` clears it. Senders, LinkedIn wait settings, reaction\nsettings and `withdrawAfterHours` are kept when omitted, and so are a workflow's paths and\nan If / else's settings; set `withdrawAfterHours: null` to turn withdrawal\noff. Steps match by order (a workflow's by `key`, so the file can keep the\norder it was written in), or by `stepId` from `steps get --with-ids` to edit\nonly some; a step saved since you read it is refused, not overwritten. After\nlaunch a workflow's paths (`key`, `next`, `yesNext`, `noNext`) and what an\nIf / else checks (`check`, `conditionField`, `conditionOperator`) stay fixed;\nits `conditionValue` and a `wait_for_connection`'s `connectionTimeoutHours`\ncan still change. On a draft, changing `check` or `conditionOperator` drops\nthe saved settings the new check doesn't use.\n\nFor a plain list, `steps.json` is a JSON array of step objects, in send\norder (max 20). A workflow wraps them as\n`{\"stepModel\":\"workflow\",\"steps\":[...]}` (see Workflows below). Each step\nhas a `type` and only the fields that type uses. For a campaign with sender\npools configured as above, omit step sender ids. A plain list:\n\n```json\n[\n { \"type\": \"linkedin_visit\" },\n {\n \"type\": \"linkedin_connection\",\n \"linkedinMessageBody\": \"Hi {{First name}}, enjoyed your post on {{Topic || \\\"AI\\\"}}.\"\n },\n { \"type\": \"wait\", \"waitHours\": 48 },\n {\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Thanks for connecting, {{First name}}. Quick question: …\",\n \"linkedinMessageMode\": \"wait_until_connected\",\n \"connectionTimeoutHours\": 336\n },\n {\n \"type\": \"email\",\n \"emailSubject\": \"Quick question, {{First name}}\",\n \"emailTextBody\": \"Hi {{First name}}, …\",\n \"onlyIf\": \"not_connected\"\n },\n { \"type\": \"wait\", \"waitHours\": 72 },\n {\n \"type\": \"email\",\n \"emailReplyToPrevious\": true,\n \"emailHtmlBody\": \"<p>Bumping this, {{First name}} — worth a look?</p>\"\n }\n]\n```\n\n| `type` | Required | Optional |\n|---|---|---|\n| `wait` | `waitHours` (> 0, up to 2160 = 90 days) | — |\n| `email` | `emailSubject` (unless `emailReplyToPrevious`); `emailHtmlBody` and/or `emailTextBody` | `emailReplyToPrevious` (thread under the last email sent to this person, no new subject); `onlyIf` |\n| `linkedin_visit` | — | — |\n| `linkedin_connection` | — | `linkedinMessageBody` (the invite note, ≤ 300 chars; the request goes out without it if LinkedIn refuses the note); `withdrawAfterHours` (168–2160, or `null` to turn off) |\n| `linkedin_message` | `linkedinMessageBody` (≤ 3000 chars) | `linkedinMessageMode`; `connectionTimeoutHours` (plain lists; a workflow uses `wait_for_connection`) |\n| `linkedin_like_post` | — | `likeReaction`; `likeMaxPostAgeDays`; `likeSkipPreviousWait`; `likeSkipNextWait`; `likeCount` (1–3 recent posts, default 1); `onlyIf` |\n| `linkedin_inmail` | `linkedinMessageBody` (≤ 1900 chars) | `inmailSubject` (≤ 200 chars; use this, not `emailSubject`) |\n| `condition` (If / else, workflows only) | `check`; `yesNext` (Yes) and `noNext` (No); with `check: \"field_value\"`, `conditionField`, `conditionOperator` and (except `is_empty` / `is_not_empty`) `conditionValue` | — |\n| `wait_for_connection` (Wait for them to accept, workflows only) | `yesNext` (Accepted) and `noNext` (Not accepted) | `connectionTimeoutHours` (the window: 24–2160 = 1–90 days, default 720) |\n\nIn a workflow every step also takes a `key` and a `next`; `condition` and\n`wait_for_connection` take `yesNext` and `noNext` instead of `next`.\n\nLegacy campaigns without a pool for a channel still require\n`emailMailboxAccountId` on email steps and `linkedinAccountId` on LinkedIn\nsteps, on Wait for them to accept (`wait_for_connection`) steps and on If / else\nsteps that check `linkedin_connected`. `steps get` / `steps set` preserve those\nvalues until conversion.\n\n- **What `steps set` and `steps edit` refuse** (so nothing is lost or sent\n raw): a field the step type would drop (`onlyIf` off an email or post-like step, a body on\n a visit, `emailReplyToPrevious` on the first email, condition fields its\n `check` or `conditionOperator` ignores), a missing subject or\n body, an invite note over 300, a message over 3000, an InMail body over 1900\n or InMail subject over 200 characters, out-of-range reaction/withdrawal/\n acceptance-window settings, `likeCount` outside 1–3,\n a wait of 0 or over 2160 hours, more than 20 steps, `{TOKEN}` with single\n braces, and workflow paths that don't hold together (Workflows below). It\n warns when several LinkedIn messages after a connection request each wait 30\n days for the accept, and when a plain list saved on a workflow campaign has\n a message after the connection request, which then no longer waits for the\n accept (Workflows below). An email with both `emailHtmlBody` and `emailTextBody`\n sends the HTML: when you edit only the text, the HTML copied from `steps get`\n is dropped (with a warning) and the new text is sent.\n- `onlyIf` — email and post-like steps in a plain list: `always` (default),\n `connected` (run only if the person accepted the LinkedIn connection),\n `not_connected` (send only if they have not). `connected` without an\n earlier `linkedin_connection` step is a launch warning. In a workflow,\n branch with an If / else (`\"check\": \"linkedin_connected\"`) instead.\n- `linkedinMessageMode` — plain lists: what a `linkedin_message` does while\n the invite is still pending: `wait_until_connected` (default when a\n `linkedin_connection` step comes before it) waits up to\n `connectionTimeoutHours` (1–2160 hours, default 720 = 30 days) then skips;\n `skip_if_not_connected` (default otherwise) skips right away. In a\n workflow a message never waits on its own (the default is\n `skip_if_not_connected`): put it on the Accepted path of a\n `wait_for_connection`, or the Yes path of a `linkedin_connected` If / else.\n- `withdrawAfterHours` — connection requests only. After 168–2160 hours\n (7–90 days), withdraw a still-pending invitation sent by this campaign.\n It never withdraws an unrelated invitation or an accepted connection.\n Omitted on creation or `null` means off; there is no automatic withdrawal\n default. A value of `600` means 25 days after the invitation was sent.\n- `likeReaction` — one of `like` (default), `celebrate`, `support`, `love`,\n `insightful`, `funny`. `likeMaxPostAgeDays` is a whole number from 1 to 365,\n default 30. `likeCount` (1–3, default 1) is how many posts to react to.\n The step chooses their newest eligible original posts and skips when none\n is available or (with one post) it was already reacted to. With\n `likeCount` above 1 a post already reacted to doesn't use one up, and\n fewer recent posts means fewer reactions.\n `likeSkipPreviousWait: true` checks for eligible posts before the wait\n immediately before this step starts. If there are none, it skips that wait\n and the like step, **keeping the following waits**, even when\n `likeSkipNextWait` is true. Earlier consecutive waits remain. Omitted means\n false, so existing campaigns keep their behavior. For example, Wait 2 days →\n Like → Wait 1 day → Message becomes Wait 1 day → Message when no eligible\n posts are found. New like steps created in the editor enable this option\n and set `likeSkipNextWait` to false.\n `likeSkipNextWait` defaults to `true` when omitted: **a reaction skipped\n during normal execution also skips\n consecutive wait steps immediately after it**, including a skip caused by\n `onlyIf`. Set it to `false` to preserve those waits. Omitting these fields\n in `steps edit` preserves their saved values.\n- InMail automatically skips people who are already connected. Do not add\n `onlyIf` or `linkedinMessageMode` to an InMail step. LinkedIn Premium InMail\n through the personal inbox is supported, not Sales Navigator or Recruiter\n InMail. Available InMail credits are checked; an open profile may be free.\n If InMail is unavailable or has no credits, the step skips rather than\n falling back to another send. Read the warnings from `launch --check`.\n- **Merge tokens** work in subjects, bodies and LinkedIn text:\n `{{First name}}`, `{{Company}}`, `{{Job Title}}` — any column of the\n enrolled record or value supplied with the person, plus `firstName`,\n `lastName`, `name`, `company`, `email`. Chain fallbacks with `||`:\n `{{First name || \"there\"}}`. A plain token with no value for a person is a\n **launch blocker** for that person (a quoted fallback avoids it); on a\n launched campaign such people are skipped at `add` time\n (`skippedMissingInfo`). AI-line tokens use their saved fallback until the line\n is written and never block launch.\n\n#### Workflows (branching paths)\n\nA workflow is a campaign whose steps say where each one goes, so different\npeople take different paths through the same campaign (the app shows it as\nthe campaign's Sequence tab). Use one whenever the brief has an \"if\".\n\n**How the Sequence tab draws them.** Each ordinary `wait` is a separate,\nclickable step (for example, \"Wait 2 days\") between actions. Add one from\n**+ → Flow → Wait**, then click it to edit the amount and unit. Waits can\nalso go before End; deleting an action keeps the wait before it.\nA `linkedin_connection` card carries the `wait_for_connection` right after\nit (**Wait up to** N days, paths Accepted / Not accepted) and, when the only\nway into the request is the No exit of a `linkedin_connected` If / else,\nthat check too (**If already connected → Separate steps for existing\nconnections**, a third path).\nThe acceptance window stays on the connection request; the add menu does\nnot offer a separate Wait for them to accept step. The stored steps below\nkeep the same timing and paths.\n\n**Keyboard editing in a draft.** Select a node and press Delete or Backspace\nto remove it; a branching node asks which path to keep. Use **⌘Z** to undo and\n**⌘⇧Z** to redo (**Ctrl+Z** / **Ctrl+Shift+Z** or **Ctrl+Y** on Windows).\nUndo restores the node's content and connections, including after deleting\nthe last node. In a message or other text field, the shortcuts edit the text\nnormally. Sequence history is kept for the current campaign editing session.\n\n**Keys and paths.** Give every step a `key`: a short id like `\"invite\"`,\nunique in the campaign, never `\"end\"`. Then say where it goes:\n\n- `condition` (If / else) and `wait_for_connection` (Wait for them to accept)\n have two exits, both required: `yesNext` and `noNext` (Yes / No, or\n Accepted / Not accepted). They take no `next`.\n- Every other step has one exit, `next`. Left out, it is the step listed\n after it in the file, or `\"end\"` after the last one.\n- An exit is another step's `key`, or `\"end\"`: that path stops there and the\n person is done with the campaign. Any path can end anywhere, so one branch\n can stop after an InMail while the other goes on.\n- **Merges**: several exits may point at the same step. Write a message once,\n then point the If / else's Yes exit and the Wait for them to accept step's\n Accepted exit at it; everything after it is shared.\n\n**If / else** (`\"type\": \"condition\"`) sends nothing. It checks the person\nwhen they reach it and takes Yes or No (`check`):\n\nIn the editor, a new If / else starts with **Choose a condition**. Select a\ncheck in its settings; the unfinished step can be saved as a draft, but a\ncondition must be chosen before launch.\n\n| `check` | Yes when |\n|---|---|\n| `linkedin_connected` | they are connected to the sender on LinkedIn (No without a LinkedIn profile) |\n| `has_email` | they have an email address that can still be emailed (not bounced, unsubscribed or marked as spam) |\n| `opened_last_email` | they opened the last email sent to them. Needs an email before it on every path and open tracking; put a wait between the email and the check so people have time to open it (`launch --check` warns otherwise) |\n| `field_value` | a field on their lead matches (Field value): `conditionField` (the field's name, like `\"Job Title\"` or `\"Source\"`), `conditionOperator` and, except for the empty checks, `conditionValue` |\n\nField value reads the person's lead, or their own record if they have no\nlead, when they reach the If / else. The campaign itself changes `Status`,\n`Last touch` and `LinkedIn connection` as it runs (How it shows up in the CRM,\nbelow): after the first send everyone is `Contacted`, so don't branch on\nthose to mean \"before we wrote to them\". Pick a field the campaign doesn't\nwrite.\n\nField value operators (`conditionOperator`), all case-insensitive:\n\n| `conditionOperator` | Yes when the field |\n|---|---|\n| `is` | equals `conditionValue` (on a multi-value field: any of its values does) |\n| `is_not` | does not equal it (none of its values do) |\n| `contains` | contains it as text (any of its values does) |\n| `is_empty` | has no value |\n| `is_not_empty` | has a value |\n\n**Wait for them to accept** (`\"type\": \"wait_for_connection\"`) sends nothing.\nFrom when the person reaches it, it waits up to `connectionTimeoutHours`\n(the window: 24–2160 hours = 1–90 days, default 720 = 30 days) for the\nconnection request to be accepted. It takes Accepted as soon as they accept\n(right away if they were already connected) and Not accepted when the window\ncloses, the invitation is withdrawn or it never went out. It needs a\n`linkedin_connection` before it on every path. Keep that request's\n`withdrawAfterHours` longer than the window, or leave it off: a withdrawal\nduring the wait ends it as Not accepted.\n\n**Rules.**\n\n- Paths only move forward: no loops, no exit back to an earlier step, and\n every step reachable from the first. At most 20 steps, If / else and Wait\n for them to accept included.\n- The server stores the steps in path order, which can differ from the\n file's; the paths, not the order, decide who gets what. `steps get` shows\n the stored order and `dench campaign get` lists each step's paths.\n- A reply-in-thread email (`\"emailReplyToPrevious\": true`) needs an email\n before it on every path that reaches it; it threads under the last email\n sent to that person.\n- Branch with If / else and Wait for them to accept, not `onlyIf` and\n `linkedinMessageMode`: in a workflow a `linkedin_message` never waits for\n the accept on its own. A plain list file (no keys or paths) saved on a\n workflow campaign runs as a workflow too, so a message after its connection\n request skips anyone who hasn't accepted yet: edit the file `steps get`\n prints instead. `steps set` warns about such a list, and `launch --check`\n about any message some path reaches after a connection request without a\n Wait for them to accept or a `linkedin_connected` If / else.\n- Steps with a `key`, a path or one of these two types save the campaign as\n a workflow, and a workflow stays one (`\"stepModel\": \"linear\"` is refused).\n For a plain list again, start a new campaign with `dench campaign draft`\n and set the steps there. Don't use `dench campaign duplicate`: the copy is\n still a workflow, so a plain-list `linkedin_message` would no longer wait\n for the accept. `steps get` prints a workflow\n as `{\"stepModel\":\"workflow\",\"steps\":[...]}`; `steps set` and `steps edit`\n take that file back as is.\n- After launch the structure is fixed: step types, keys, paths (`next`,\n `yesNext`, `noNext`) and what each If / else checks (`check`,\n `conditionField`, `conditionOperator`). `steps edit` still changes text,\n waits, `conditionValue` and the window of a Wait for them to accept. To\n change the structure, `dench campaign duplicate <c>`, fix the copy and add\n only people who were never contacted.\n\n**Workflow launch blockers** (`launch --check` names the step):\n\n| Blocker | What's wrong | Fix |\n|---|---|---|\n| `workflow_path_invalid` | the paths don't hold together: two steps share a key, an exit names a key no step has, a path goes back or loops, nothing leads to a step, or an If / else or Wait for them to accept misses an exit. Also fires when a plain list holds one of those two steps | fix `key`, `next`, `yesNext` and `noNext` in the file, then `steps set` |\n| `wait_for_connection_without_invite` | a path reaches a Wait for them to accept with no connection request before it | add a `linkedin_connection` earlier on that path |\n| `opened_check_without_email` | a path reaches an `opened_last_email` If / else with no email before it | send an email earlier on every path to it, or check something else |\n| `open_tracking_unavailable` | email opens aren't tracked, so `opened_last_email` would always say No | check something else |\n| `condition_field_missing` | a `field_value` If / else names a field the campaign's leads don't have | `dench crm fields list lead` (for people with no lead, the object they were added from, like `dench crm fields list people`), then use one of those field names |\n| `reply_without_prior_email` | a path reaches a reply-in-thread email with no email before it | send an email earlier on every path to it, or give it its own `emailSubject` |\n\n**Example: connected or not, an acceptance window and an InMail fallback.**\nPeople already connected get the message right away. Everyone else gets a\nconnection request (withdrawn after 25 days if still pending); those who\naccept within 10 days get the same message, the rest get an InMail and\nstop. After the message: a 2-day wait, a reaction to two recent posts, a\nday, then a follow-up. Supply `Fund` for each person (or use a deliberate\nfallback); do not guess investor data. Sender pools still come from the\ncampaign settings.\n\n```json\n{\n \"stepModel\": \"workflow\",\n \"steps\": [\n {\n \"key\": \"connected\",\n \"type\": \"condition\",\n \"check\": \"linkedin_connected\",\n \"yesNext\": \"pitch\",\n \"noNext\": \"invite\"\n },\n {\n \"key\": \"invite\",\n \"type\": \"linkedin_connection\",\n \"withdrawAfterHours\": 600,\n \"next\": \"accept\"\n },\n {\n \"key\": \"accept\",\n \"type\": \"wait_for_connection\",\n \"connectionTimeoutHours\": 240,\n \"yesNext\": \"pitch\",\n \"noNext\": \"inmail\"\n },\n {\n \"key\": \"inmail\",\n \"type\": \"linkedin_inmail\",\n \"inmailSubject\": \"Fellow {{Fund}} founder\",\n \"linkedinMessageBody\": \"Hi {{First name}}, fellow {{Fund}} founder here. We wrote a short report on how teams like {{Company}} handle this. May I send it?\",\n \"next\": \"end\"\n },\n {\n \"key\": \"pitch\",\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Hi {{First name}}, fellow {{Fund}} founder here. We wrote a short report on how teams like {{Company}} handle this. May I send it?\",\n \"next\": \"pause\"\n },\n { \"key\": \"pause\", \"type\": \"wait\", \"waitHours\": 48, \"next\": \"like\" },\n {\n \"key\": \"like\",\n \"type\": \"linkedin_like_post\",\n \"likeReaction\": \"like\",\n \"likeMaxPostAgeDays\": 30,\n \"likeCount\": 2,\n \"next\": \"pause2\"\n },\n { \"key\": \"pause2\", \"type\": \"wait\", \"waitHours\": 24, \"next\": \"report\" },\n {\n \"key\": \"report\",\n \"type\": \"linkedin_message\",\n \"linkedinMessageBody\": \"Hi {{First name}}, is the report useful for {{Company}}?\",\n \"next\": \"end\"\n }\n ]\n}\n```\n\nExplain the mapping to the user like this: \"if connected\" is the\n`connected` If / else; \"else a connection request\" is its No exit to\n`invite`; \"wait 10 days\" is `accept` (`connectionTimeoutHours: 240`); its\nAccepted exit merges into the same `pitch` as the Yes exit; Not accepted goes\nto `inmail`, which ends. Everything from `pitch` on is one shared path. In\nthe app that is one \"Send connection request\" card with Already connected,\nAccepted and Not accepted paths and \"Wait up to 10 days\"; the 2-day and\n1-day waits appear as separate steps before the Like and follow-up cards.\n\nSave on a draft, inspect the round trip, then check readiness without sending:\n\n```bash\ndench campaign steps set <campaign> --file steps.json --json\ndench campaign steps get <campaign> --with-ids\ndench campaign launch <campaign> --check --json\n```\n\nThe REST operations `campaigns.steps.replace` and `campaigns.steps.update` use\nthe same field rules. When replacing a workflow's steps, send\n`\"stepModel\": \"workflow\"` so they are checked the way they will be saved.\nUpdates require `stepId`, `type` and `expectedUpdatedAt`; only supplied fields\nchange. Defaults are not re-applied to a partial update.\nKeep the campaign at a reviewed draft until the user approves real sends.\n- **Account ids.** `dench campaign accounts --json` returns `mailboxes` with\n `emailMailboxAccountId` and `linkedinAccounts` with `linkedinAccountId`.\n Both lists honor the acting member's connection visibility: their own\n private accounts and teammates' shared accounts, never someone else's\n private account. LinkedIn discovery also excludes removed accounts,\n former members' accounts and mock connections. It needs a live member's\n API key or agent session; an organization-only key is refused.\n LinkedIn summaries contain display/owner labels, status, availability,\n `remainingToday` (`invites`, `messages`, `profiles`) and\n `remainingInvitesThisWeek`. Today's invites also respect the rolling\n seven-day limit. Mailbox summaries include warm-up status, when a new\n mailbox is ready and its daily cold-send cap. These are account-local usage\n snapshots before queued work and campaign limits, not send reservations. Pool\n updates validate both the editor's and campaign owner's access; launch and\n dispatch still validate availability. Use only the Dench account ids in a\n campaign pool.\n API equivalent for LinkedIn discovery: `GET $DENCH_API_BASE/campaigns/accounts/linkedin`\n with the same bearer credentials; no caller-supplied user or workspace id.\n\n### AI-written lines\n\n```bash\ndench campaign personalize get <campaign>\ndench campaign personalize set <campaign> --file lines.json\ndench campaign personalize write <campaign> [--all] [--yes]\ndench campaign personalize edit <campaign> --person <enrollmentId|name> --line <key> --text \"…\"\ndench campaign personalize rewrite <campaign> --person <enrollmentId|name> [--line <key>]\ndench campaign personalize clear <campaign>\n```\n\nUp to 5 lines per campaign, about 3 cents a person. `lines.json` is\n`{\"sells\":\"…\",\"lines\":[{\"label\",\"instructions\",\"fallback\"}]}`; optional per\nline: `key` (otherwise made from the label), `maxChars` 20-300 and `fallbackFrom`\n(a field to use before the fallback). `set` writes lines for up to 100 people\nright away; more waits for `write --yes`, which confirms the cost. `write --all`\nrewrites everyone; `edit --text \"\"` undoes a manual edit. `clear` turns lines\noff; take the `{{keys}}` out of the steps first.\n\n### Per person\n\n```bash\ndench campaign stop <campaign> --person <enrollmentId|name> [--json] # nothing more is sent to them\ndench campaign remove <campaign> --person <enrollmentId|name> [--json] # drafts only: drop someone never contacted\ndench campaign resume-person <campaign> (--person <enrollmentId|name> | --all) [--json]\ndench campaign person set <campaign> --person <enrollmentId|name> [--email ada@new.com] [--linkedin-url <url>] [--field \"Job Title=CTO\" ...] [--json]\ndench campaign sync <campaign> [--json] # fill empty email, LinkedIn URL, name and fields from CRM records\n```\n\nEnrollment ids come from `dench campaign people`. A person's name works\nwhen it is unique in the campaign. `stop` on a never-contacted person in a\ndraft removes them, which frees their place in the 300-person cap. `remove`\nrefuses anyone already contacted. `resume-person --all` resumes every paused\nperson in an active campaign, for example after a sender was reconnected.\n`person set` fixes an address or fills a `{{merge field}}` before launch (a\ncorrected email, LinkedIn URL or matching column also updates the linked CRM\nrecord); `--field` repeats. `sync` fills each unfinished person's empty email,\nLinkedIn URL, name and merge fields from their linked CRM record, for example\nafter enriching the records; it never overwrites a value the campaign already\nhas.\n\n### Launch and lifecycle\n\n```bash\ndench campaign launch <campaign> --check [--json] # readiness only; never launches\ndench campaign launch <campaign> [--ack-linkedin-risk] [--json]\ndench campaign pause <campaign> [--json]\ndench campaign resume <campaign> [--json]\ndench campaign archive <campaign> [--json] # stops everyone still in flight; final\n```\n\n`launch --check` runs only the readiness check and never launches. It\nprints each blocker with why it fires and the commands that fix it\n(`reasons` and `fix` on every entry of `blockers[]` in `--json`), the\nwarnings, the audience and step counts and the `fingerprint`, then exits 0\nwhen the campaign is ready and 1 when it is blocked. Run it before every\nlaunch: plain `launch` launches as soon as the campaign is ready, so it is\nnot a dry run. `start` is another name for `launch`, including `--check`.\n\n`launch` runs the same check first. When something is missing it\nprints every blocker in plain words — no steps, nobody enrolled, a step's\nmailbox or LinkedIn account missing or disconnected, people without an\nemail or URL, people missing a merge field the steps use, a reply-to-thread\nstep with no earlier email, people enrolled in another LinkedIn campaign —\nand exits 1 without launching. Fix them (`steps set`, `add`, `set`) and run\n`launch` again. `--json` prints the full readiness payload (`blockers[]`\ngrouped by problem with the affected people, `warnings[]`).\n\nCampaigns with LinkedIn steps need `--ack-linkedin-risk`: automated\nLinkedIn activity is against LinkedIn's terms and can get the account\nrestricted. Say so to the user and pass the flag only once they accept.\n\nStatus moves `draft → active → (paused ↔ active) → completed`, and\n`archived` from anywhere. `pause` only acts on an active campaign, `resume`\nonly on a paused one; both say when there is nothing to do. `completed`\nmeans everyone finished, replied or stopped; adding people to a completed\ncampaign revives it.\n\n## Reading `dench campaign get`\n\n```\nFounder outreach — active [js7…]\nSchedule: Mon-Fri 9-18 America/Los_Angeles · up to 30 emails/day · stops on reply\nSteps (4): Visit profile → Connect on LinkedIn → Wait 2d → Email\n\nFunnel\n Enrolled 120\n In flight 38 (active 36, paused 2)\n Contacted 80\n LinkedIn invited 60 · accepted 22 · messaged 18\n Email sent 75 · opened 30 · clicked 4\n Replied 9 (11.3% of contacted)\n Done finished 30 · stopped 5 · failed 1\n\nNow / Next\n Now: Sending a connection request to Grace Hopper (since Sep 2, 2026, 10:41 AM)\n Next: Send an email to Ada Lovelace at Sep 2, 2026, 10:44 AM (in 3m)\n Held: today's email cap is reached · resumes Sep 3, 2026, 9:00 AM (in 22h)\n Emails today: 30/30 · next email Sep 3, 2026, 9:00 AM (in 22h)\n Sender Mark R: running · invites 12/25 today, 40/100 this week · messages 3/40 today · 09:00-18:00 America/Los_Angeles (in window)\n\nPeople (50 of 120)\n Ada Lovelace — active · waiting: email · until Sep 2, 2026, 10:44 AM (in 3m) · last: invite sent 2d ago · lead: Contacted [enr_…]\n Grace Hopper — active · sending: connect on linkedin · hold: the sender's daily LinkedIn limit is reached (until …) [enr_…]\n Linus T — replied · last: LinkedIn message sent 5h ago · lead: Replied [enr_…]\n```\n\n- **Funnel**: `Enrolled` = everyone ever added. `Contacted` = got at least\n one email, invite or message (a profile visit does not count). `Replied`\n counts replies from people this campaign contacted, whether or not the\n reply stopped them; the rate is replied / `Contacted`. `Done` splits\n finished (reached the end), stopped (stopped, bounced, complained,\n unsubscribed) and failed. In a plain list a finished person ran every\n step; in a workflow they reached the end of their path, so someone on the\n Not accepted → InMail path finishes without the steps on the other path.\n- **Now** is the one action being sent this instant; **Next** is the next\n action and when. `Held` explains why nothing is going out.\n- **Hold reasons** (on `Next`, on a person, or as `Held`), in plain words:\n the campaign is paused · a sending account is disconnected · today's email\n cap is reached · outside the sender's working hours · outside the\n campaign's send window · the sender's daily LinkedIn limit is reached ·\n the sender's weekly connection limit is reached · spacing out sends so\n they look human · checking whether they are already connected · paused\n after LinkedIn errors · the LinkedIn account is paused · LinkedIn asked\n us to retry later · writing personalized lines (shown on a person as\n `note: Waiting for personalized lines`; after 2 hours the saved fallback\n text is sent). Every one of these clears on its own; none means a\n step \"did not send\". Report the hold, not a failure.\n- **People**: status, what their current step is doing, the last delivered\n step, any hold, and the linked lead's `Status`. `--json` returns `{\n detail, analytics, live }` — the raw campaign (`detail.enrollments`,\n `detail.currentRuns[enrollmentId].hold`, `detail.lastTouches`,\n `detail.connectedEntries[enrollmentId].lead`), the funnel and the live\n strip.\n\nA workflow's `get` lists its paths, counts each exit and shows the\nacceptance waits:\n\n```\nSteps (9, a workflow with paths):\n 1. If / else: Connected on LinkedIn? → Yes: LinkedIn message (step 5) · No: Connect on LinkedIn (step 2)\n 2. Connect on LinkedIn\n 3. Wait for them to accept (up to 10d) → Accepted: LinkedIn message (step 5) · Not accepted: LinkedIn InMail (step 4)\n 4. LinkedIn InMail → End\n 5. LinkedIn message\n …\n\nFunnel\n …\n Done finished 3 · stopped 0 · failed 0\n Paths step 1 If / else: Connected on LinkedIn? → Yes 12 · No 40\n step 3 Wait for them to accept → Accepted 9 · Not accepted 14\n\nNow / Next\n Next: Wait for Ada Lovelace to accept the connection request — next check Sep 2, 2026, 12:41 PM (in 2h), stops waiting Sep 7, 2026, 10:41 AM (in 5d)\n\nPeople (50 of 52)\n Ada Lovelace — active · waiting: Wait for them to accept · stops waiting Sep 7, 2026, 10:41 AM (in 5d) [enr_…]\n Grace Hopper — active · checking: If / else: Connected on LinkedIn? [enr_…]\n```\n\n- **Steps**: one line per step in the stored order. A step names where it\n goes only when that isn't the next line; `→ End` ends that path. If /\n else and Wait for them to accept name both exits.\n- **Paths**: how many people have taken each exit so far (`branchStats` in\n `--json` analytics). The two numbers can add up to less than `Enrolled`:\n people before the step, or on another path, haven't reached it.\n- **Next** for a Wait for them to accept: when Dench next checks for the\n accept, and when it stops waiting and takes Not accepted. `Check\n \"<label>\" for <name>` is an If / else about to run.\n- **People**: `checking: <If / else>` while an If / else or Wait for them to\n accept reads the profile (nothing is sent); `waiting: Wait for them to\n accept · stops waiting …` until they accept or the window closes.\n\n## How it shows up in the CRM\n\n- **Lead `Status` moves on its own, forward only**: the first delivered\n email, connection request or LinkedIn message moves New → `Contacted`; a\n reply moves it to `Replied`. Nothing sets `Qualified` / `Disqualified` or\n moves backwards, and a `Status` outside New/Contacted/Replied is left\n alone. `Last touch` is bumped on every send, acceptance and reply. Never\n hand-edit `Status` after a step ran — you would race the writeback.\n- **Lead `LinkedIn connection` tracks the relationship, forward only**: a\n connection request sets `Invited`; an acceptance — or finding the person\n is already a connection — sets `Connected`. The column is created on the\n lead object the first time a LinkedIn step runs; email-only campaigns\n never touch it.\n- Every touch is also an event on the lead's History tab (source\n \"Campaign\") and in `dench campaign events`. `dench crm history <object>\n <entryId>` shows the field changes under the actor `Campaign: <name>`.\n- Enrolling a `people` row links its lead's `Contact` to that person; that\n link is expected — leave it.\n\n## REST API and app SDK\n\nAll paths are under `/api/v1` and need member-bound credentials. Agents can call\nany operation through `dench.api.call(operationId, args)`, and the typed\nmethods are under `dench.campaigns` (see [APPS.md](./APPS.md)). The full\nrequest and response schemas are in [API.md](./API.md) and `openapi.json`.\nOperation ids below are `campaigns.<name>`:\n\n| What | Operations |\n|---|---|\n| Browse and inspect | `list`, `get`, `analytics`, `live`, `events`, `preview`, `pipeline`, `people.timeline`, `people.forRecord`, `accounts.email`, `accounts.linkedin` |\n| Create and configure | `create`, `drafts.create`, `update`, `duplicate`, `archive` |\n| Add people | `audience.search`, `people.addFromSearch`, `people.addBatch` (50 recipients), `people.addFromCrm` (100 ids), `people.add`; saved lists via `lists.rows` and `people.addBatch`, retaining each row's `personalization` |\n| Steps | `steps.replace` (draft), `steps.update` (also after launch) |\n| AI lines | `personalization.get`, `.set`, `.write`, `.edit`, `.rewrite`, `.clear` |\n| Per person | `people.stop`, `people.remove`, `people.resume`, `people.resumeAll`, `people.setEmail`, `people.setLinkedin`, `people.setField`, `people.sync` |\n| Launch | `launch.preview` (`GET /campaigns/{sequenceId}/launch`, returns the `fingerprint`), `launch` (`POST`, needs that `fingerprint`), `pause`, `resume` |\n| Builder | `builder.profile`, `.autofill`, `.estimate`, `.lookalike`, `.voices`, `.save`, `.get`, `.build`, `.opener`, `.sequence`, `.outreach`, `.create`, `.drafts`, `.resume`, `.discard` |\n| Signals | `sources.overview`, `.get`, `.signals`, `.update`, `.preview`, `.run`, `.pending`, `.review`; `queue` |\n\nSearch bodies are `{ \"filters\": { … }, \"limit\": 50 }` with an optional\n`pageToken`; batch bodies are `{ \"recipients\": [ … ] }`. There is no reply-text\nendpoint: combine `campaigns.get` with the CRM activity of the person, or use\n`dench campaign replies`.\n\n## Rules\n\n- `steps set` works only in draft; `steps edit` changes text and waits after\n launch. Schedule, daily cap, stop-on-reply, start and end change any time\n before archive.\n- One campaign, one schedule: all steps share the send windows; LinkedIn\n steps also respect the LinkedIn account's own working hours and limits.\n- Max 300 people per campaign, 20 steps, 100 ids per CRM `add` batch and 50\n people per search or file batch (the CLI chunks for you), 8 send windows,\n 300 characters per invite note, 3000 characters per LinkedIn message.\n- Outreach needs a **workspace member's** credentials: a `dench signin`\n session, a member-bound `DENCH_API_KEY`, or an agent session a member\n created. With an organization-only key every command fails with\n \"Outreach needs a workspace member's credentials\". That is about whose\n credentials the run has, not about sending accounts — connecting a\n mailbox changes nothing. Ask the user to run it from a chat in the Dench\n app (or to link their account in Slack) so the run carries their\n identity, rather than retrying.\n- `dench email multichannel …` drives the same campaigns with fewer\n controls; prefer `dench campaign`.\n- HTTP equivalent: `$DENCH_API_BASE/campaigns…` (the Campaigns section of\n `references/API.md`; operationIds `campaigns_*` in `openapi.json`). `launch` there needs the `fingerprint` from\n `GET /campaigns/{sequenceId}/launch`.\n\n## What still needs the user in the Dench app\n\n- Signing in to a mailbox or LinkedIn account (`dench tool connect` prints the\n link), reconnecting or disconnecting it, and a mailbox's warm-up sign-in.\n- A mailbox's daily cold-send cap, skipping its warm-up and sharing it with\n teammates; a LinkedIn account's daily and weekly limits, working hours and\n risk acknowledgement.\n- Answering replies in the Inbox.\n"
|
|
32
32
|
},
|
|
33
33
|
"references/CLI.md": {
|
|
34
34
|
"sha256": "4cf770b52942820d9f5bc085fd826c31c1f834010d26bcecbbe20293dff6834d",
|