By KYN AI Advisory Team — AI implementation specialists, Singapore
An external agent can sync with Salesforce in three ways: poll the REST API, subscribe to change events, or load in bulk. For most SMEs the right start is change events for live updates plus a scheduled bulk or query job as a safety net. Whichever you choose, the agent writes through a dedicated integration user with narrow permissions, keeps its own ID map, and sends nothing outbound without a named person's approval.
What does an external agent need from Salesforce?
Before you pick a pattern, list the data the agent reads and writes. A sales agent usually needs:
- Read: Accounts, Contacts, Leads, Opportunities, Tasks, Emails and the custom fields that mark status.
- Write: Tasks and notes (the log), field updates like "last contacted" and "reply label", and draft records. Rarely: stage changes.
- Never: deleting records, changing ownership in bulk, or editing price books.
Then decide where the source of truth sits for each field. If Salesforce owns the contact record and the agent owns the "reply label", each writes only its own fields. Overlap is where syncs break.
For a related insurance case, see Salesforce email automation for Singapore insurance brokers.
Which sync patterns exist?
| Pattern | How it works | Good for | Weak at | |---|---|---|---| | Polling | Agent calls REST or SOQL on a schedule, filtered by last-modified time | Small data, simple start | Latency, uses API requests, misses deletes unless handled | | Change events | Salesforce publishes record changes; the agent subscribes | Near-real-time reaction | Allocation limits, replay and ordering handling | | Bulk load | Bulk API 2.0 jobs move large sets | Initial load, nightly reconciliation | Not interactive, batch limits | | Outbound push from Salesforce | Flow or Apex calls the agent's endpoint | Event-driven with logic in Salesforce | Needs Salesforce build work, harder to test |
The pattern choice depends on volume and how fast the agent must react. A reply desk that must label an inbound email within a minute wants events. A weekly pipeline report is fine on polling.
What do Salesforce limits mean for the design?
Salesforce meters API use. The API request limits and allocations page describes a daily limit counted over a rolling 24 hours across REST, SOAP, Bulk and Connect API calls. For Enterprise Edition it starts at 100,000 requests per 24 hours and rises with licences. When you exceed it, the API returns HTTP 403 with REQUEST_LIMIT_EXCEEDED.
For SMEs, that number is large enough for a well-built sync and small enough for a careless one. A loop that re-queries every Contact every five minutes will burn it. Design rules:
- Query only changes. Filter on
SystemModstamporLastModifiedDategreater than your last cursor. - Use composite and bulk calls where a single call can carry many records.
- Cache reference data such as picklists and user lists. Refresh daily.
- Track usage. Read the limits endpoint and alert at 70% of the daily allocation.
- Back off on 403 with REQUEST_LIMIT_EXCEEDED. Pause until usage drops, and tell a person.
Bulk API has its own allocations. Salesforce's Bulk API limits cap batches per rolling 24 hours, shared between Bulk API and Bulk API 2.0, and query jobs have their own cap. A nightly reconciliation is well inside this. A chatty bulk job that fires on every event is not.
Change events and platform events have separate delivery allocations. Salesforce documents these in its Change Data Capture allocations guide, and the delivery allocation is shared between high-volume platform events and change data capture events. The default depends on the edition. Check yours before you subscribe to all objects. Subscribe to the few objects and fields the agent needs.
How do you keep the two systems consistent?
Whatever pattern you pick, five habits prevent most sync bugs.
- Own your ID map. Store the Salesforce record ID next to your own ID for every synced record. Never match on name or email alone.
- Idempotent writes. Every write carries a key. If a call times out and you retry, the second call updates the first result, not a duplicate. Use an external ID field and upsert.
- Cursor with overlap. Keep a "last synced" timestamp and re-read a few minutes before it. Duplicates are cheap. Gaps are not.
- Reconcile nightly. A scheduled job compares counts and checksums for each object in both systems and lists mismatches. A sync with no reconciliation is a sync you hope works.
- Handle deletes. Polling does not see deleted records unless you query for them. Change events include delete events. Decide what the agent does when a record disappears: archive its own copy and stop work on it.
When both systems edit the same field, pick a rule: last write wins, Salesforce wins, or conflict goes to a person. Do not leave it implicit.
How should you set up access?
- Dedicated integration user. One user per agent, never a person's login. Name it for the agent so the audit trail is readable.
- Permission set, not profile sprawl. Grant object and field access that matches the read and write list above. Check field-level security on every field the agent touches.
- Connected app with OAuth. Use a flow suited to server-to-server access, such as the JWT bearer flow with a certificate, and restrict the connected app to the integration user. Store the key in a secrets manager.
- IP restrictions and session policies where your plan supports them.
- Sandbox first. Build and test against a sandbox. Refresh it before each test cycle so data matches production.
Salesforce's own agent products exist, and some teams will prefer them. An external agent makes sense when the workflow spans more than Salesforce, such as WhatsApp, Gmail and your finance system, or when you want the agent, its rules and its logs to sit in your own cloud account.
Which actions need a person?
The integration user's permissions are the hard limit. On top of that:
- Outbound email or message to a contact: approval.
- Stage change to closed won or closed lost: approval.
- Merge or delete of any record: approval, and ideally not allowed to the agent at all.
- Mass update of more than a set number of records: approval and a dry run first.
The agent logs the proposal, the approver and the result. See how to set approval gates for high-risk agent actions.
Where KYN fits
KYN builds agents that sit beside the CRM you already run. For an insurance brokerage, we built outreach with one checkable first line and a reply desk that sorts replies, with the log written back so the next person sees the state. Agents use their own restricted accounts, every action is logged with the actor, and outbound messages wait for a named person. The system runs in a cloud account in your name. See sales systems and integrations.
The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days.
Frequently asked questions
Should the agent poll or subscribe to change events?
Subscribe when the agent must react within minutes. Poll when daily or hourly freshness is enough. Add a nightly reconciliation either way, because both patterns can miss records.
Will an external agent use up our Salesforce API allowance?
Not if it queries only changes and caches reference data. A badly designed polling loop can. Track usage against the daily allocation and alert before you hit it.
Can the agent write to Salesforce without an approval?
For low-risk fields such as a reply label or a logged task, yes. For outbound messages, stage changes, merges and deletions, a named person approves.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
