> ## Documentation Index
> Fetch the complete documentation index at: https://docs.agentlinkops.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Prepare a campaign for your existing CRM and sender

> Prepare a reviewed campaign handoff, map it to your existing CRM or email sender, and reconcile placement evidence without confusing drafts with sent messages.

Use AgentLinkOps with your existing CRM and email sender to prepare a qualified campaign, then check claimed placements. Your agent keeps the audience judgment and drafts. Your CRM keeps relationships; your sender keeps delivery, replies and suppression records.

This guide follows the local toolkit's `qualified-campaign-handoff` and `placement-reconciliation` recipes, version `1.0.4`, reviewed September 14, 2026. The examples use fictional records. No CRM or sender connection has been tested for this guide. Check [capability status](/capability-status) for hosted operations.

## Choose the task and the records

Give your agent the asset URL and publication state, audience, supplied publisher pages, campaign purpose and outreach constraints. Choose where to keep the handoff: an existing CRM, a file or a shared document. A ledger and SQLite CRM are optional.

If you have the supplied toolkit with the `linktrail-setup` skill, ask:

```text theme={null}
Use linktrail-setup to prepare a campaign for my existing CRM and sender.
Use the qualified-campaign-handoff recipe and supplied publisher records.
Check the asset's publication state, evidence and my exclusion rules.
Prepare reviewed drafts and preview the destination field mapping.
Keep missing facts unknown. Save a portable handoff if access is missing.
Do not send messages or activate a sequence.
```

With an authorized checkout or supplied package, preview setup from your chosen working directory:

```bash theme={null}
node /path/to/linktrail/cli/linktrail.mjs setup --plan --goal prepare-campaign --mode external
```

Replace `/path/to/linktrail` with your package location. This command writes nothing and connects no accounts. It inspects known local path metadata; it does not read your records or verify credentials. A plan is a starting checklist. If your package lacks this command, use the recipe directly. See [CLI access](/guides/connect-cli).

Supplied-input preparation needs no AgentLinkOps account. Fresh checks need page access. Hosted operations need the selected tool, account permission and available service access; installing a skill grants none of these.

## Qualify before handing off

Inspect each exact publisher page and record the relevant context, retrieval date and evidence limits. A domain alone cannot establish a relevant page. Keep eligible, rejected and unresolved candidates separate, with reasons. The [campaign workflow](/campaign-workflows) covers audience fit and published contact routes.

Check current reply and suppression records in the chosen sender. If access is missing, leave the handoff unready for sending. Do not guess contact addresses or claim deliverability from an address found on a page.

Run the site's content workflow on each draft, including source review, a separate humanizing pass and the final review. A draft cannot claim that you inspected a page, own an asset or represent its author unless the evidence supports that sentence.

## Map a portable handoff

Use stable record references and preserve existing external IDs. The labels below describe a handoff document; they are not vendor field names or an import schema.

| Logical label       | Fictional supplied value                                |
| ------------------- | ------------------------------------------------------- |
| Record reference    | `campaign-demo-001`                                     |
| Publisher page      | `https://publisher.example/resources`                   |
| Asset URL           | `https://brand.example/guide`                           |
| Recipe and revision | `qualified-campaign-handoff@1.0.4`, draft `r1`          |
| Qualification       | Unresolved: current page and suppression checks pending |
| Destination mapping | Not inspected                                           |
| CRM write           | Not attempted                                           |
| Sender state        | Unknown                                                 |
| Link observation    | Not checked                                             |

Before writing to a CRM or sender, inspect its actual field schema and lookup behavior. Preview the selected rows, field mapping and intended changes. A CSV export, an agent's vendor connection and a hosted AgentLinkOps command are separate surfaces. This guide supplies no native sender connector or vendor-specific import command.

If authorized to save a draft, keep the operation receipt and read the destination afterward. Follow all cursor pages needed to find the selected IDs. Compare returned fields with the intended draft revision. Record accepted, rejected and unchanged rows separately. A successful command or zero-change receipt alone does not prove the draft exists there.

If access is unavailable, save the portable document with its actual state and next action. The useful result is the qualified evidence and reviewed draft; destination access can follow later.

## Reconcile a claimed placement

When the sender or publisher reports a placement, obtain its exact source page and expected destination. A reply alone supplies no link observation. For a supplied URL pair, the local CLI can check without an account or ledger:

```bash theme={null}
node /path/to/linktrail/cli/linktrail.mjs check --source 'https://publisher.example/resources' --target 'https://brand.example/guide' --scope exact --json
```

The `.example` URLs are placeholders. Replace them with the actual pair before running. The check fetches the source page, so it needs network access. Read the structured observation, reason, method and timestamp. An incomplete check remains unknown; a single-check exit zero means a result returned. See [check a placement](/guides/check-placement) and [evidence states](/evidence).

Update the selected CRM record or companion document with that observation after any required write authorization. Read it back before calling the update complete. Preserve draft revision, delivery and reply facts separately. Keep a historical observation with its original timestamp even if a later check is unknown.

For an existing ledger, preview optional monitoring uploads:

```bash theme={null}
node /path/to/linktrail/cli/linktrail.mjs sync --dry-run
```

This preview makes no network request. It previews ledger uploads, not CRM writes. Continue through [sync and export](/guides/sync-and-export) only when you want hosted history or monitoring and have the required connection.

## Resume without duplicating records

If a write times out, record `outcome unknown` with the original operation identifier. Read that operation, then read the destination again. Preserve the receipt and later field comparison separately. Do not create a fresh record to bypass an ambiguous result.

A failed operation may have partial effects. An empty lookup does not prove that nothing was saved. Keep unresolved fields unknown, retain the intended revision, and record the next permitted recovery step. Use `not attempted` only when no write occurred. Restored access permits another read; it does not prove the earlier write failed.