How to connect Claude to your CRM, step by step

By Dan Muse9 min read AI agents & MCP

Connecting Claude to a CRM can take one URL and a browser sign-in. The important decision comes next: what Claude may read, what it may change, and which actions stay with you. Start with questions, use a limited admin account, and add write access only after the answers hold up.

Key takeaways

  • The connection is a URL and a sign-in on your CRM's own domain. No key to paste into a chat window.
  • The agent acts as whoever signed in and inherits that person's permissions. The account you sign in with is your real control.
  • Spend the first week asking questions. The return is the reports your CRM cannot produce, not the typing.
  • Allow writes on contacts, deals, notes and segments. Keep sending, money, merges and anything bulk.
  • Expect the failure to be a call that succeeds and quietly does the wrong amount, not a refusal.
On this page

What connecting involves

Your CRM publishes an address. Claude asks that address what it can do, reads the menu at the moment you ask, and acts inside your account from there.

On AXL that address is one URL, and access comes from a browser sign-in rather than a key you hand over. The client receives an ordinary admin token scoped to one account, which is why the agent sees exactly what you see.

  1. 01 Add the server One URL, pasted once. Claude → Connectors
  2. 02 Sign in Approve on your CRM's own domain. Browser
  3. 03 Ask something A question, not an instruction. Any chat
  4. 04 Allow one write Something small you can reverse. Later that week

The exact command, the menu path and the things that fail at sign-in are on the Claude connector page. That part is easy. Everything below is about the days after.

The first week: ask, do not act

A CRM report answers the questions someone anticipated when they built it. Everything else is an export and a spreadsheet. That is the constraint an agent lifts, and it is worth a week before you allow a single write. Questions that used to cost forty minutes:

  • Which customers have paid us more than $500 in total, and what did they buy?
  • Which deals have sat in one stage longest, what are they worth, who owns them?
  • What happened with this customer, in order, since they first landed on the site?
  • Who came in from last month's campaign, has a phone number, and never opened an email?
  • Who watched most of the replay and did not order? Exactly how many is that?

None of these are new capabilities. Each is a filter your CRM already supports and you were never going to build by hand: 74 conditions on AXL, 61 of which also work as a saved segment or a campaign audience, which is how an answer becomes a list you keep using.

One question, four calls

“Which customers have paid us more than $500, and what did they buy?”

capability_map area=sales get_extended_filter_schema PaymentsAmount invoke_operation crm.Lead.Count invoke_operation crm.Lead.GetItems.get

It counts the matches before it reads the rows. So should you.

Those calls run through the same permission checks as the web interface, so a field you cannot see stays invisible to the agent. It reads your data rather than auditing it, though: three spellings of one company still means three answers.

If your CRM, your checkout and your email are three products, an agent can only answer a third of the question. See what one contact record holding all three looks like.

What the agent can see

A contact is one row. On AXL, "contact", "lead" and "student" are one record seen from three angles, so the person who clicked the ad and the person halfway through your course are not two rows to reconcile. Ask about customers who never finished onboarding and the agent has one place to look.

A deal is a card on a board. It belongs to a contact, sits in one stage of one pipeline, and carries an amount, an owner, tags and whatever custom fields that pipeline defines. Moving it is the write you will use most.

A segment is a saved question, not a copied list. Save "paid more than $500, no order in ninety days" once and it re-evaluates whenever something reads it.

The writes worth allowing

A useful rule: allow the writes whose worst case is a tidy-up, and hold back the ones whose worst case is an email your customers have already read.

  • Contacts

    Create, correct, tag, assign an owner. Email is the identity, so a duplicate is refused rather than quietly created.

  • Deals

    Open a deal on a stage, move it, change the amount or the owner. Reversible by moving it back.

  • Notes and tasks

    Write up a call, put a follow-up on someone's list for Thursday. The dullest win, and the one people keep.

  • Segments

    Save the filter it just built. Keep them personal at first. A shared one needs its own permission, which is the right friction.

  • Imports

    Hand it a messy list and it maps the columns. A field it does not recognise stops the batch and asks rather than guessing.

  • Orders, but not payment

    Drafting an order is safe: it is a document. Marking it paid is a second, separate call, and that one is yours.

The writes to keep on yourself

Sending. This is the one people get wrong. An email campaign here has no draft state: creating one schedules it, and a campaign scheduled for "now" is on the wire in about a second. Let the agent build the audience and write the copy. Say "send" yourself, in its own sentence.

Money. Recording a payment is what moves an order to paid, and a refund is the same call with a different status. Both are one line to write and awkward to explain afterwards.

Merging duplicates. Finding them is a perfect agent job. Merging them is irreversible. There is no unmerge, so have it produce the list and approve in batches you have read.

Anything bulk. Bulk operations take a filter, and an empty filter means every record in the account. A bulk delete with no filter is refused outright here, but a backstop is not a policy. Ask for the count before the action, every time.

Permissions and billing. These you do not have to police. Twenty-one sensitive operations (billing writes, API-token minting, role and permission changes, and creating admins) are removed from the AI surface in the server, so the tools are not there to call. The full list is here →

A confirmation flag is not a person. The caller sets it on itself, so read it as a speed bump against a slip, never as proof that somebody agreed.

There is a simpler lever than any of this, and most people miss it: sign in as a smaller account. The agent inherits the permissions of whoever authorized it, so make a second admin login with only the rights you want it to have, and connect with that. Five minutes of setup, and the boundary is enforced by your CRM rather than remembered by you.

Four things that go wrong

The call that succeeds and does nothing. Not every condition applies to every field. Ask for one the platform cannot express that way and it is ignored rather than rejected: clean response, wrong list. Which is why "how many is that?" is the most useful thing you can say before "go ahead".

The move that loses fields. Moving a deal into a stage of a different pipeline clears its tags and custom field values, because those belong to the pipeline it left. That is deliberate, the interface does it too, and nothing in the response mentions it. Across pipelines, read the deal first.

The contact that comes back. Deleting a contact is a soft delete, which is good news when you want it undone. It is a surprise when an import a month later hits the same email and restores the old record instead of creating one. Check what a large import will touch first.

The summary you did not ask for. When a six-step job fails at step four, what you hear about is the four that worked. End every multi-step instruction with "then tell me exactly what changed".

What it costs

Two bills, and only one is real. On the AXL side the MCP server is part of the platform and tool calls are not metered: they sit behind a concurrency limit rather than a quota, so a machine caller runs three requests at a time and a long job is paced instead of blocked. Some vendors meter instead, at a few thousand calls a month. Find that number before you build on it.

The bill you will notice is your AI subscription, because tokens scale with how much data you pull into the chat. Asking for a count is nearly free. Asking it to read five thousand records and sort them itself is not, and it is the slower answer: a filter the CRM evaluates costs one call.

FAQ

Do I need a developer for this?

No. You paste a URL into a settings screen and sign in, the way you would connect a calendar. You need a developer to build one of these, not to use one.

Can Claude see everything in my account?

It sees what the person who signed in can see, in that one account, and every call goes through the same permission checks as the web interface. For a smaller boundary, connect with an admin login that has fewer rights.

Should I let it write on day one?

No, and not because it is dangerous. A week of questions teaches you what it is reliably good at, and that is the list worth automating. Starting with writes means learning the same lesson with your data.

What happens if it gets something wrong?

It depends what it touched. Most records here are soft-deleted and can be restored, and a deal that moved can move back. A merge cannot be undone and a sent email cannot be recalled, which is why those two stay with you.

My CRM is not AXL. Does any of this apply?

The shape does. Ask your vendor three questions: how much of the product the agent can reach, whether it can write or only read, and which operations they removed from the AI surface. The third answer tells you the most.

Ask your own pipeline a question tonight.

One URL and a browser sign-in, and the assistant you already pay for can read your contacts, deals, orders and email in one place. Publishing and sending stay separate, deliberate steps.

Go deeper in the docs
  • Filtering and search terms: the conditions an agent composes when you ask a question.
  • Deals: stages, amounts and per-pipeline fields, as the interface shows them.