Lock CRM writes to a single custom field

Why this matters

CRM data is the system of record for the revenue forecast. Once an agent has write access to deal stage, amount, or close date, a single bad call rewrites the pipeline. The damage is not catastrophic in a software sense, the API call succeeds, but the downstream effects (forecast moves, commission calculations shift, executives get bad numbers in the Monday meeting) are real and hard to roll back.

The pattern that protects you without ruling out useful CRM-write workflows is field-level scoping: the agent reads everything it needs (contact history, prior notes, related opportunities, parent account context) and writes only to one custom field, typically named auxot_research_summary or similar. The field is a free-text or rich-text type so the agent’s output fits without schema friction. Forecast-bearing fields stay manual.

Two-locks framing makes this structural. Lock one is the Auxot tool policy: the agent’s write tool is allowed only when targeting the named custom field. Lock two is the CRM-side field-level permission: the integration user (the service account the MCP authenticates as) has write permission only on the custom field, read-only on everything else. Either lock alone is insufficient; tool policies can be loosened in a rewrite, CRM permissions can be loosened by an admin who does not know the agent depends on the restriction. Both locks together mean a wrong write fails twice.

Nothing rewrites the forecast: you review the agent’s summary, you decide whether anything in that summary justifies a stage change, you make the stage change by hand.

Quick start

1. Create the custom field in your CRM: auxot_research_summary (or whatever name fits the work). Type: long text / rich text. Default permission: read-only for all users; write permission granted only to the integration user via a dedicated permission set.
2. Configure the CRM-side field permission set: in Salesforce, a permission set assigned only to the integration user; in HubSpot, a custom property with edit access limited to the integration user; in Pipedrive, custom-field-level permissions on the field. The non-integration permissions (sales reps, managers) get read-only on the custom field so they can still see what the agent wrote.
3. Wire the CRM MCP (Add an MCP server): the official Salesforce hosted MCP for Enterprise Edition and above (generally available April 2026), the official HubSpot MCP for HubSpot (free tier covers the connector), Composio Pipedrive for Pipedrive. Authenticate as the integration user, not a personal account.
4. Restrict the tool policy to the one field (Define a tool policy): the agent’s tool policy must scope write tools to the named custom field only. Block any write tool that does not accept a field parameter (some connectors expose bulk-update tools that write multiple fields at once; those have no path to enforce the single-field rule).
5. Test the policy with a forecast-field write attempt: ask the agent to write a test value to deal stage. The write should fail twice: first at the Auxot tool-policy layer (policy rejects the call), and even if the policy ever loosens, the CRM-side field permission denies the integration user write access to stage. If either lock is missing, fix it before any real run.

Done? A CRM with one custom field the agent can write to, a tool policy in Auxot that prevents the agent from writing anywhere else, and a CRM-side permission set that fails the write at the API layer if the tool policy is ever loosened.

The agent can do that?

1. Inventory the CRM fields and pick the custom-field target

Chat → Admin Agent:

CRM platform: [Salesforce / HubSpot / Pipedrive]. Object: [Account / Contact / Deal]. Paste the current field list (or describe the schema). Job: recommend one custom field to add as the agent's write target (typically a long-text or rich-text type), name it conventionally (e.g., `auxot_research_summary`), and list the fields that must stay read-only for the integration user (deal stage, amount, close date, owner, forecast category, anything that flows into the revenue rollup). Output the CRM-side permission-set spec the admin should apply, not a write tool call.

Why it’s non-obvious: Asking the agent to enumerate the forecast-bearing fields up-front catches CRM-specific quirks (Salesforce has Forecast_Category__c separate from StageName; HubSpot has dealstage plus hs_forecast_probability; Pipedrive has stage plus expected close date). The integration user’s permission set must block writes on all of them, not just the obvious ones.

2. Lock the tool policy

I'm writing a tool policy for an agent that writes to [Salesforce / HubSpot / Pipedrive] via [official MCP / Composio]. The agent must only be able to write to custom field `auxot_research_summary` on the [object] object. List the tool policy rules needed: which read tools to allow (the agent needs to read everything to write a useful summary), which write tools to allow with field-name parameters, which write tools to block entirely (any bulk-update tool that targets multiple fields). Flag any write tool where the policy cannot enforce the field-name parameter and CRM-side field permission is the only proof.

Why it’s non-obvious: Some CRM MCPs expose a single update tool that writes all fields on the object; others expose per-field write tools. The per-field shape is enforceable at the policy layer; the bulk shape is not. If your CRM MCP only exposes bulk update, the CRM-side field permission becomes the primary lock and the tool policy is documentation. The agent helps you see which case you are in.

3. Operating note for the human review step

Custom field name: `auxot_research_summary`. CRM platform: [name]. Object: [name]. Field type: [long text / rich text]. Owner of the review: [name, may rotate]. Produce a one-page operating note: (1) what the agent's summary is for (research handoff to a rep, not a stage change), (2) who reads the summary and when (Friday-morning pipeline review, before a customer call), (3) what triggers a manual stage change (the summary is one input among several; a stage change is always a human decision), (4) what to do when the summary contradicts the current stage (raise it in the next pipeline review; do not edit the stage from the summary alone). Tone: factual, no apology language. The note lives beside the CRM schema doc so anyone joining the team can read it cold.

Why it’s non-obvious: The two-locks pattern protects the forecast structurally, but the human side has to know why the field is structured this way. Without an operating note, the next admin who joins the team sees a custom field with restricted permissions and “fixes” it by loosening permissions. The note is the answer to “why is this field locked down?” before the admin gets curious.

Go deeper

Why not “let the agent edit deal stage directly”

Three reasons. First, deal stage moves the forecast. A miscalibrated agent will move stages too aggressively (every “interested” prospect becomes “qualified”) or too conservatively (every meeting-completed deal stays “stage 1” until a human moves it), both bad. Second, the forecast is a planning instrument used by people who do not see the agent’s reasoning. They see only the new stage. The summary field gives reps a place to record context that explains why the stage might warrant a change, without the agent making the change. Third, the structural separation between “agent writes context” and “human decides forecast” is what the field-level pattern teaches the team: the agent is a research assistant, not a forecast author.

CRM-specific wiring notes

For Salesforce, the official hosted MCP became generally available in April 2026 for Enterprise Edition customers and above. Authentication is through a connected app tied to the integration user. Create a permission set named something obvious (Auxot_Agent_Write) with field-level write access only on auxot_research_summary, field-level read on everything else, and assign it to the integration user only. Salesforce’s permission model is the most granular of the three; use it.

For HubSpot, the official MCP covers all paid tiers and the free tier. Custom properties have edit access controlled at the user level. Create the integration user, assign them a custom permission set that grants edit on the custom property and read-only on everything else. HubSpot’s permission model is less granular than Salesforce’s; verify in the UI that the integration user cannot see the “edit” button on deal stage when logged in as the integration user.

For Pipedrive, Composio’s Pipedrive connector is the standard wiring path. Field-level permissions are configurable per custom field on paid tiers. The integration user is a paid seat. Test with a stage-change attempt by the integration user in the Pipedrive UI before wiring the agent; the API enforces the same permissions, so a UI-side block means an API-side block.

The case for a read-only-everything-else integration user

Some teams ask whether the integration user needs read access to fields it cannot write. Yes: the value of the summary field is that it reflects the full context (contact history, prior notes, related opportunities). If the integration user cannot read deal stage, the summary cannot reference it. Read-everything-write-one-field is the right shape, not read-only-the-one-field.

Troubleshooting

• The agent’s summary contradicts the current stage and no one notices. The pattern is working; the human side is not. Add a Friday-morning pipeline-review cadence where the rep reads the summary alongside the stage. The summary is a forcing function for that review, not an automatic correction.
• The integration user can write to forecast fields when tested through the API. The CRM-side permission set is misconfigured. Re-check: in Salesforce, the integration user has been assigned only the locked-down permission set, not the standard sales-user profile; in HubSpot, the integration user is on the custom permission set, not the default “Sales” role; in Pipedrive, the field permission is set per-field, not at the role level.
• A second agent needs to write to a different custom field. Add a second custom field (auxot_call_notes or whatever fits), update the integration user’s permission set to allow writes on both, scope the second agent’s tool policy to the second field. Do not let two agents share a write field; the audit trail gets harder to read.

Variations and edge cases

• The CRM is a custom in-house system. The pattern still applies: a database column the agent can write to, a database-level permission that scopes the integration user, an Auxot tool policy that names the column. The two locks are platform-independent.
• Multiple agents write to different fields on the same object. Each agent gets its own custom field and its own scoped tool policy. The integration user has write access on all the agent-fields, read on everything else. Audit trails stay per-field, which means per-agent.
• The team uses a CRM without field-level permissions. Rare in May 2026, but possible for self-hosted or lightweight tools. In this case the Auxot tool policy is the only lock, and the operating note should explicitly say so. Treat the policy as load-bearing and add a second human-review step before any merge to forecast-bearing fields.
• The custom field needs to be searchable in the CRM UI. Most modern CRMs index custom text fields for search by default. If your CRM does not, add an explicit search-index configuration step before wiring the agent; otherwise the summary is invisible to the reps who need to read it.

Walkthrough

Step 1: Create the custom field in your CRM

Log into the CRM as an admin. Navigate to the object you are wiring (Account / Contact / Deal). Add a custom field named auxot_research_summary (or your team’s chosen name). Field type: long text or rich text, depending on what the CRM offers. Field length: at least 4000 characters so the agent has room to write a useful summary. Default permission: read-only for all users.

Step 2: Create the integration user and the permission set

Create a dedicated user account for the agent integration. In Salesforce, this is a “User” record assigned to a dedicated profile with minimal base permissions. In HubSpot, this is a paid seat. In Pipedrive, this is a regular user seat. Name the account obviously: auxot-integration@yourcompany.com or similar.

Create a permission set (Salesforce) or custom role (HubSpot, Pipedrive) named Auxot_Agent_Write. Grant: write access on auxot_research_summary only, read access on all fields needed for context (contact history, prior notes, related records). Block: write access on stage, amount, close date, owner, forecast category, anything that flows into the revenue rollup. Assign the permission set / role to the integration user.

Step 3: Wire the CRM MCP

Open Settings → MCP servers in Auxot. Add the CRM connector (Add an MCP server). Walk through the OAuth flow using the integration user’s credentials (not a personal account). After the connection is live, run a single read tool call to verify the connector can see the object (the agent should list a few records back to you).

Step 4: Write the tool policy

Open Settings → Tool Policies (Define a tool policy). Create a new policy. Allow the read tools the agent needs for context. Allow the write tool only when the field-name parameter equals auxot_research_summary. Block any bulk-update tool that targets multiple fields at once.

Step 5: Test both locks

Ask the agent to write a test value to deal stage. The write should fail at the Auxot tool-policy layer (the policy rejects the call). Then loosen the tool policy temporarily (for testing only) and ask the agent to retry. The write should still fail, this time at the CRM API layer (the integration user does not have write permission on stage). Restore the strict tool policy. If either lock is missing, fix it before any real run.

Step 6: Write the operating note

Use power move 3 to draft. Edit until the note covers the four points (what the field is for, who reads it, what triggers a manual stage change, what to do when summary contradicts stage) in a way a new admin could read cold. Store the note beside the CRM schema doc, a wiki page, or as a description on the custom field itself if your CRM supports field-level description text.

What’s next

• → Add an MCP server. The MCP wiring layer this pattern depends on.
• → Define a tool policy. The field-scoping mechanism that makes the agent’s write structural.
• → Turn account research into CRM field updates. The canonical consumer of this pattern: account research summarized into one custom field for the rep to read before a call.
• → Run a deal desk for pricing and legal exceptions. The deal-desk flow uses the same field-level safety pattern when summarizing approval context on a deal.
• → View your audit logs. When you need to verify which CRM write tool fired and which field it touched.
• → Require human approval before risky actions. When you want a human-step gate on top of the field-level lock, for the highest-stakes write paths.

Reference

• Pattern name: Field-level CRM safety pattern. Foundational pattern; foundation for any CRM-write tutorial.
• The one custom field: auxot_research_summary (or your team’s convention). Long text or rich text. Read-only for everyone except the integration user.
• Two locks: (1) Auxot tool policy scopes the agent’s write tool to the custom field; (2) CRM-side field permission blocks the integration user from writing to forecast-bearing fields.
• Forecast-bearing fields (always read-only for the integration user): deal stage, amount, close date, owner, forecast category, expected revenue, anything that flows into the revenue rollup.
• Salesforce wiring: official hosted MCP (generally available April 2026, Enterprise Edition and above), connected app + integration user + permission set.
• HubSpot wiring: official MCP (covers free tier and all paid tiers), integration user + custom property + custom permission set.
• Pipedrive wiring: Composio Pipedrive connector, integration user (paid seat) + custom field + field-level permission.
• The human-review step: the agent’s summary is one input among several. A stage change is always a human decision, made in the CRM UI, after the rep reads the summary.
• Operating note discipline: lives beside the CRM schema doc; explains the locked-down field permissions so the next admin does not loosen them.
• When the two-locks pattern is overkill: never. The CRM-side permission set takes ten minutes to configure once and protects every future agent that writes to the CRM.