What a connected assistant can and cannot do

A connected assistant reads your workspace by default: pipelines, buyers, rules, leads, delivery traces and reports, for your organization only.

Changing anything needs a permission you tick on purpose, and every change will be shown to you as a preview and applied only after you approve it.

It never charges a card, never refunds money, never deletes anything, and never touches your credentials — whatever it is asked.

The same permissions apply to the in-app assistant: what it can propose is what your own seat could do by hand, and what your organization has left switched on.

Every change is previewed

Asking an assistant to change something does not change it. It sends back a preview — what would change, what it would affect, and whether it can be undone — and a token that is worth nothing until you say yes.

1. You ask. The assistant quotes the preview's first line, then shows you the changes and the warnings.
2. You approve. The assistant confirms.
3. LeadMove rechecks everything and applies it, in one go.

Every preview starts with one line you can decide on: what it does and to what, what that means in numbers, and whether it can be undone.

Pause Acme Solar · 2 rules stop, ~40 leads a month go elsewhere · reversible for 7 days

The assistant quotes that line word for word before it asks for your yes, and in the in-app assistant it is the title of the card. The changes and warnings below it are there when you want the detail. In Claude.ai and Claude Desktop the preview arrives as the same card, with that line as its title (what you see in Claude). The card's Apply is the same approval as saying yes: LeadMove rechecks everything the same way.

Between step 1 and step 2 the preview goes stale after 10 minutes, and if somebody edits the same thing in the meantime the change is refused and you are shown a fresh preview instead. Nothing is ever half-applied.

What "change configuration" can change

Everything the buyer screens accept, through the same rules the screens use — a setting added to LeadMove is available to an assistant the day it ships, without a separate release.

Buyers. Create one, copy one under a new name, and change any of its settings: price per lead and conditional pricing, daily, weekly and monthly caps and the days their cycles reset on, volume carried over from elsewhere, operating hours and timezone, what happens out of hours, contact details, tags, notes, the duplicate window, the dispute window and allowance, delivery branding, the fields its portal hides, its status, and a temporary closure.

A buyer an assistant creates arrives paused, because a buyer with no delivery endpoint receives leads that go nowhere. Ask for it to go live once the endpoint is in place. A copy arrives paused too, with every copied endpoint disabled — so a lead cannot reach the original client's destination by accident — and without the original's routing rules.

Delivery endpoints. Add one, change where or how it delivers (a JSON body, form fields or URL parameters, the body template or the rows it sends, whether the lead's attribution is included), enable or disable it, choose which one a buyer uses by default, and send one sample lead to it to check it works. On an endpoint with a body template the sample goes out in that format, and the answer names any field that went out empty. The preview shows the request the endpoint will make, with fixed values masked, for example GET https://crm.example.com/lead?key=•••&email={email}.

Two settings on a buyer are deliberately not part of this:

• Portal login details are credentials. Set them yourself in the buyer's portal access panel.
• The billing mode has a request of its own, because switching between invoice and prepaid changes what stops that buyer's deliveries. See billing modes.

Routing rules. Create one, change any of its settings, switch rules on and off in bulk, and copy one onto another buyer or another pipeline. A rule covers its name, its pipeline, its buyer, its conditions, its tier and tier name, its weight, its price and conditional pricing, its field mapping and which of the buyer's endpoints it delivers through.

A rule an assistant creates arrives switched off and flagged for review, so you can read it before the next lead is routed by it. Ask for it to go live — turn that rule on — once you are happy. Say activate: true in the same breath if you want it live immediately; the preview repeats it back before you approve.

Every rule preview carries the last 30 days, replayed: how many of your real leads the rule would have matched, roughly what they would have cost, and whether the buyer's daily cap would have held.

Would have matched 114 of 380 leads in the last 30 days (≈ 3.8/day); ≈ $25.00/lead, $2,850.00 over the window; cap 50/day exceeded on 3 days.

It is counted as if the rule were first in line: a rule in a later tier only sees what the earlier tiers did not take, and caps, hours and balances are not replayed. Treat it as a ceiling. See routing rules.

The preview also warns about the things people ship by accident — a rule with no conditions takes every lead, a buyer with no endpoint or on pause receives nothing, a price under the buyer's usual applies to every lead the rule takes, a tier with nothing above it is simply skipped.

Pipelines. Create one, copy one under a new name, and change any of its settings: its name and description, its status and tags, its field schema and required fields, the inbound mapping and transforms, its spam rules, its duplicate fields, window and action, its distribution mode and method, its manual review gate and auto-release delay, and the retry that picks leads back up when capacity returns.

A pipeline an assistant creates arrives paused, so its fields and its routing can be checked before a real post arrives. A copy arrives paused too, with the routing rules copied and the sources copied under new posting keys.

Two of its settings are replayed over your real intake before you approve, the same way a rule's are:

With a 7-day window on email, 38 of the last 30 days' 412 leads would have been duplicates.

Roughly 412 leads a month would wait for review. Each one releases itself after 30 minutes if nobody gets to it.

What a pipeline sends outside LeadMove — the auto-reply that texts or emails the lead, the conversion postbacks that call a third party, and forwarding into another pipeline — is a separate request, graded like an endpoint change: every owner is emailed when one lands. Arming a channel still needs its prerequisites first, Twilio for SMS and a verified sender domain for email.

Sources. Add one to a pipeline, rename it, change the mapping from a partner's field names to yours, and switch it on or off. See sources and posting URLs.

Setting up several things at once

An insertion order is never one object. Acme Solar, California and Nevada, $25 exclusive, 50 a day, webhook https://hooks.acme.com/leads with a bearer token is a buyer, an endpoint and two rules — and approving those one at a time means four chances to approve something half-built, with no way back once the third has landed.

So paste the order and ask for it in one go. What comes back is one preview: a tree of what would be created, the warnings gathered in one list, the 30-day replay for each rule, and one token.

Pipeline Solar CA (existing, unchanged)
Buyer Acme Solar (new, paused)
  webhook https://hooks.acme.com/leads (new, disabled)
  Rule "Solar CA → Acme (CA)": Solar CA → Acme Solar, 25, tier 1 (new, disabled)
  Rule "Solar CA → Acme (NV)": Solar CA → Acme Solar, 25, tier 1 (new, disabled)
Everything is created paused or disabled.

One yes creates all of it, in a single transaction: it either all exists or none of it does. Undoing it undoes all of it too — the buyer archived, the endpoint and the rules switched off.

• Anything already in your account is read, never modified. Say on Solar CA and the pipeline is referenced, fingerprinted and left alone. If somebody edits it between the preview and your yes, the whole thing is refused and re-previewed rather than half-applied.
• The one exception: endpoints for a buyer you already have. The tree says so (Buyer Acme Solar (existing, +1 endpoint)), the endpoint still arrives disabled, and the setup counts as a sensitive change: every owner is emailed when it lands.
• At most 20 things per setup. Past that, split it — the pipeline and its buyers first, the rules after.
• Asking twice does not create twice. Each setup carries a key; replaying it returns what was already created and names it, which is what makes a workflow safe to retry.

Keeping a proposal for later

Any preview can be kept instead of confirmed — hold that, I want a colleague to check the numbers. A kept proposal lives 7 days, and the assistant can list what is waiting and throw one away.

Reviewing drafts in Settings

Kept proposals appear in Settings → Developers → Assistant drafts, which is where the colleague finds one without ever opening Claude. The section only exists while something is waiting.

Review opens the proposal recomputed against today's data — not the copy that was saved. That is the point of the wait: a proposal written on Friday describes Friday, and what you approve on Monday has to be what would actually happen on Monday. When something it touches has been edited in between, a banner says so above the diff.

What you see is the same preview the assistant showed: the summary, the diff (a tree, for a setup that builds several things), the warnings, what else happens outside the change, and whether it can be undone. Then Apply, and the session is the confirmation — you read it and clicked, which is exactly what confirming from the conversation means.

Discard throws it away. Nothing it described was ever created, and nothing is undone; it simply stops waiting.

Applying needs the same role the change itself needs, so a proposal that records a buyer payment shows Apply greyed out to an admin and works for an owner. The org switches apply too: if assistant configuration changes are switched off, a waiting proposal cannot be applied until they are back on.

Its confirmation token still expires in ten minutes, so a kept proposal is never applied from the old token. Asking the assistant again also works, and gives you a fresh preview in the conversation.

What "act on leads" can do

Everything an operator does at the dispatch desk, on up to 50 leads at a time, at 10 actions a minute.

Ask in your own words — approve the twelve waiting on Solar CA except the ones without a phone, and send them to Acme — and what comes back is a verdict per lead: what would happen to each one, or why it would be skipped and whether overriding would push it through.

Once delivered, a lead can't be taken back. Undoing a send or an approval calls back the deliveries that are still queued — the buyer's slot returns, a compensation credit re-opens and a prepaid charge is refunded, exactly as the Cancel button does — and tells you which leads had already gone out. A delivered lead stays delivered and stays counted against that buyer's cap: the cap reflects what actually happened. The preview says all of this before you approve, not after.

Field edits can't be undone automatically. They are the one change with no undo, and it is a choice rather than a limitation: putting the old values back means storing them, and a lead's field values are a person's contact details. The change log keeps them for two years and is read by everyone who can open it. So the preview shows the shape of each change — email: not a valid email → a valid email — and the previous values stay where they always have, on the lead's own activity.

A test lead has to be made up. Simulating a lead with the email or phone of somebody already in your account is refused. Give it values with the right shape that belong to nobody.

Sending a lead in review approves it at the same time, and the preview says so. A lead a forwarding rule transfers to another pipeline can only be approved, never sent from here — it is not this pipeline's to deliver.

What "record buyer payments" can do

Two things, both of them book entries. Money is collected outside LeadMove; this records that it arrived.

• Record a payment. A positive amount on a prepaid buyer's balance, with a reference you must supply — the invoice number or transfer id. If a buyer is stopped for insufficient balance, the preview says so and their deliveries resume the moment you approve.
• Record an adjustment. A signed correction with a reason — a write-off, a mistyped amount.

Both require the Owner role, are previewed like everything else, and email every owner when they land.

Limits. At most $5,000 per entry and $10,000 a day per connection, inside LeadMove's own ceiling of $100,000 for a single manual entry. You can lower a connection's limits from its page.

A reference is recorded once. Asking twice with the same reference on the same buyer is refused and points at the entry that already exists — which is what makes a workflow safe to replay.

Undoing writes an opposite entry rather than erasing one; the ledger is append-only. If the balance has been spent in the meantime and the reversal would take it below zero, it is refused, tells you what is left, and offers a partial adjustment.

Recording a payment never charges anyone. There is no card, no refund and no invoice anywhere in this permission.

Workflows

Six recipes ship with the connection. They are the account jobs that take a fixed sequence of steps, written down once so they run the same way every time. In Claude they appear under /mcp; with the plugin they are slash commands.

Nothing about them is privileged. A workflow is a message, and everything it causes goes through the same permissions, the same previews and the same approvals as a question you typed yourself. What it saves you is the order: "triage my overnight leads" is four steps in a particular sequence, and asked cold, a model picks a different one each time.

The three that only read

The three that end in something to approve

Each opens on the same rule: a write tool returns a preview, the preview is shown to you, you answer, and only then is it confirmed. A workflow that finds it is missing a permission names it and stops rather than working around it.

The workflow text is versioned and the public plugin is generated from it, so a workflow reads the same wherever you invoke it. describe_capabilities lists all six with their arguments.

Sensitive changes email the owners

Some changes are announced the moment they happen rather than in a digest, because they are the ones you would want to know about even if you were not in the conversation:

• adding, changing or enabling a delivery endpoint — where a client's leads physically go, including a setup that adds an endpoint to a buyer you already have;
• changing a buyer's phone or email when one of its SMS or email endpoints has no address of its own and sends there;
• switching a buyer's billing mode;
• every payment or adjustment on a balance.

Every owner gets an email with the diff and a link to undo it.

Undoing a change

Every change an assistant makes can be undone for 7 days, from either side. Ask it to — undo that, or undo everything you just did — or click Revert in the activity log, on the page of the buyer, pipeline or rule that was changed, or in the email you were sent about it. It is the same undo whichever way you reach it.

A change is put back to its previous values. Something it created is archived: a buyer and a pipeline are archived, a source is disabled. A routing rule it created is deleted, the same as the Delete button on the pipeline's rules, so it no longer counts as one of the buyer's rules; the leads it already routed keep their history. Money is compensated by an opposite entry rather than erased.

If somebody edited the same thing after the assistant did, the undo refuses rather than discarding their work: it tells you what they changed, and offers to put back only the fields the assistant moved and leave the rest alone. Something the assistant created is only removed if nobody changed it since; otherwise the undo points you to the app to remove it by hand.

Past 7 days the undo is gone and the only route is making the opposite change — which the assistant will happily do.

Daily budget

A connection may make 200 changes a day. Reading is never affected, a routing simulation (a made-up lead run through a pipeline) is not a change and does not count, and the count resets at midnight UTC.

Past the limit it refuses, says when it resets and how to ask for more; it never silently half-applies anything, and the connection is not suspended. At 80% the account owners get one email, once a day.

You can lower a connection's budget yourself from its page. Raising it above 200 is a conversation with us.

The four permissions

A connection can never do what the person behind it could not do by hand. The role is re-read on every single request, so a demotion narrows an existing connection immediately, and a person leaving the workspace suspends theirs.

Permissions can be removed from a connection, never added. Adding one means connecting again — a dated, named event rather than a silent upgrade to a credential already sitting in someone's config.

Always off

No permission, no role and no request unlocks these. They are not settings:

• Taking payment. It cannot charge a card, refund one, change your plan or touch an invoice.
• Deleting. Nothing it reaches can destroy a record. Things get paused, archived or closed.
• Credentials. It cannot read or create an API key, a portal password, a buyer's ingestion key, or the authentication headers on a delivery endpoint. Those never appear in anything it sees.
• Another organization. Every question is answered inside yours. An ID from somewhere else reads as "not found".
• Following instructions found in your data. A lead's comment field, a buyer's error message, a dispute note — all of it is marked as third-party text to report on, never as an instruction. A supplier cannot smuggle a command into a lead field and have it acted on.

Limits

Past a limit, the request is refused with a reason the assistant can read out to you — it never silently does half the work. Limits are shown on each connection; you can lower one yourself and ask us to raise one.

Where to see what it did

The activity log records every change, named after the connection: Claude via "Ops laptop". Filter by that connection to read a session end to end.

The connection itself — Settings → Developers → Connected assistants, then open a row — shows its last calls, the tool used, whether it worked, and how long it took. Read calls are kept 30 days; changes are kept for two years.

Your inbox, for the two things worth interrupting you: a sensitive change (moving where leads are delivered) emails every owner the moment it happens, with the diff and an undo link that opens a confirmation in LeadMove rather than undoing anything by itself; and an optional daily digest, one line per connection with how many changes it made, how many were sensitive, how many somebody has already taken back and how many were decided on the card, which you turn on in notifications.

An assistant groups what it did into a session so you can undo the lot at once. For now a session means "everything one connection changed within the same clock hour" — check the list it reads back before confirming an undo of all of it.

Switching it off

Four ways, from broadest to narrowest:

1. The organization switches. Settings → Developers → Assistant access: four switches, one per permission, covering every connection at once. Turning one off stops the next request — you don't have to know which connection to revoke. All four also control the in-app assistant: with "change configuration" off, the dock stops proposing configuration changes and says so.
2. Suspend a connection. A pause you can undo. Use it while you investigate.
3. Revoke a connection. Permanent, effective on the next request. There is no un-revoke.
4. Remove a permission. Open the connection and untick it — the rest keeps working.

Owners and admins can do all four. The payments switch is owner-only.