Why Salesforce is the odd one out
Most of the CRMs Anexus supports hand you an API token to paste. Salesforce doesn't. Access to a Salesforce org runs through a Connected App — Salesforce's own OAuth container — so there is no key for you to generate, copy or look after. You click a button, Salesforce asks whether you agree, and the two systems trade tokens behind the scenes. Nothing is typed.
The trade-off is that a Salesforce org is administered, not owned by whoever happens to be logged in. Most Salesforce connection problems are not connection problems at all — they are org configuration: an edition without API access, a profile missing a permission, a validation rule nobody remembers writing, or a connection authorized against a sandbox instead of production.
First, know which org you are about to authorize
Salesforce is not one place. Almost every customer has a Production org plus one or more Sandbox orgs — copies used for testing and training. They are separate databases with separate logins:
- Production signs in at
login.salesforce.comwith your normal username. - Sandbox signs in at
test.salesforce.com, and the username has the sandbox name appended —you@company.com.uatrather thanyou@company.com.
Worth knowing too: refreshing a sandbox rebuilds it from production and invalidates anything that was authorized against the old copy. After a sandbox refresh, expect to connect again.
What has to be true in your org before you start
- A Salesforce org you can sign into — Production, Sandbox or Developer Edition.
- API access on your edition. Enterprise, Unlimited, Performance and Developer Edition include it. Professional Edition only has it when the API add-on was purchased, and the smallest editions do not have it at all. Without API access, no integration — ours or anyone else’s — can write to the org.
- The API Enabled permission on the profile or permission set of whoever clicks Connect, plus Create and Edit on the Contact object. An admin grants both in Setup.
- The Anexus app must be installed in your Salesforce org for cross-org access. If you are testing in your own org, your admin (which may be you) needs to install the Anexus package. Contact us for the install URL if you are an early customer.
- First-time approval. Many orgs set the Connected App’s Permitted Users policy to "Admin approved users are pre-authorized", which means an admin has to assign the app to a profile or permission set before anyone in the org can get past the consent screen.
Connecting Anexus to your org
In Anexus, open Settings → CRM Integrations and find the Salesforce card.
Click Connect with Salesforce. You leave Anexus and land on Salesforce’s login page.
Sign in with your normal Salesforce credentials — and take the extra second to check which org you are signing into. A sandbox username carries the sandbox name as a suffix, so the username itself is the quickest tell.
Salesforce shows a consent screen listing what Anexus is asking permission to do:
- Access and manage your data via APIs — the
apiscope, which is how Contacts get written. - Perform requests at any time — the
refresh_tokenscope, so syncing keeps working when nobody is logged in.
Click Allow.
Salesforce sends you back to Anexus. The Salesforce card flips to a green "Connected" state showing your Salesforce org ID. Compare that org ID with the one under Setup → Company Information in the org you meant to connect — it is the quickest possible confirmation that you authorized the right one.
Lead or Contact? Anexus writes Contacts
In most CRMs a person is simply a person. In Salesforce a person is one of two different objects, and which one you get matters:
- Lead — an unqualified person who is not yet attached to anything. Leads sit outside your account hierarchy until someone converts them, which creates a Contact, an Account and usually an Opportunity, and marks the Lead as converted.
- Contact — a person who belongs in your customer data, normally linked to an Account.
Anexus writes to Contact. Every captured Anexus contact becomes a Salesforce Contact record — no Lead is created, and nothing is converted. If your team works leads before contacts, that is a routing decision to make on the Salesforce side, not something to configure in Anexus.
The write is an upsert keyed on Email
Before writing, we look for a Contact with that email address in your org:
- If a Contact with that email already exists in the org, we update it.
- If it does not, we create a new one.
That order matters in Salesforce specifically, because Salesforce orgs almost always run Duplicate Rules on Contact. We never blind-insert and leave the rule to fight us for it.
Field mapping: Anexus → Salesforce
Using Salesforce’s own field API names, this is what a captured contact becomes:
| Anexus capture | Salesforce field | Notes |
|---|---|---|
| First name | Contact.FirstName | Standard field. Salesforce does not require it, so a Contact still saves without one. |
| Last name | Contact.LastName | Required by Salesforce on every Contact. If the capture has no last name, Anexus sends "Unknown" so the record can still save. |
Contact.Email | The upsert key — the field we match on before deciding to update or create. A capture without a valid email is skipped, because there is nothing to match on. | |
| Phone | Contact.Phone | The standard Phone field — not MobilePhone, and not any phone field your org added itself. |
| Job title | Contact.Title | Free text in Salesforce, not a picklist, so whatever the person typed arrives as-is. |
Backfilling contacts captured before you connected
Use Sync past contacts on the Salesforce card to push everything captured before you connected.
One Salesforce-specific caution: Salesforce meters API calls per org over a rolling 24 hours, and the allowance depends on your edition and licence count. A backfill of a few hundred contacts is small next to a typical org’s allowance — but if the org is already near its limit because of a data load or another integration misbehaving, the backfill is what tips it over, and Salesforce then starts refusing calls for everyone. Run large backfills outside your busiest hours.
Salesforce errors, and what they actually mean
Salesforce returns machine-readable error codes, and the sync status on the Salesforce card passes the real one through. These are the ones worth recognising.
"invalid_client_id" or OAUTH_EC_APP_NOT_FOUND at the consent screen
The Anexus Connected App is not present in the org you just logged into, or an admin has restricted which Connected Apps may be used. Note that an app installed in Production does not exist in a Sandbox unless the sandbox was refreshed after the install. Contact us for the install URL and pass it to your Salesforce admin.
It says Connected, but no Contacts appear in Salesforce
The records may be going to a different org. Compare the org ID shown on the Salesforce card with the one under Setup → Company Information in the org you are looking at. If they differ, disconnect in Anexus and connect again, checking which org you sign into before you approve. If the org IDs match, check the capture itself: a contact without a valid email address is never pushed, so a test entry with a junk email will not appear.
"API is not enabled for this Organization or Partner"
Either your Salesforce edition does not include API access, or the user’s profile is missing the API Enabled permission. Both are fixed only inside Salesforce: an admin grants API Enabled on the profile or via a permission set, while an edition limit needs Salesforce to sell you the API add-on. There is no workaround on the Anexus side.
INSUFFICIENT_ACCESS_OR_READONLY
The user who authorized the connection can see the org but cannot write the Contact — either their profile is missing Create and Edit on the Contact object, or the record we matched on is one your org’s sharing model does not let them edit. OAuth inherits the permissions of whoever clicked Allow, so reconnecting with the same user changes nothing. Either have an admin fix that user’s profile or permission set, or connect as someone with Create and Edit on Contact.
FIELD_CUSTOM_VALIDATION_EXCEPTION or REQUIRED_FIELD_MISSING
A validation rule or a required custom field on Contact is refusing the record, and the wording you see is your own admin’s error text — which is why this one reads like an internal policy rather than a technical fault. Ask your admin either to exempt integration writes from that rule, or to give the field a default so a Contact can save without it.
DUPLICATES_DETECTED, or "Use one of these records?"
This is a Salesforce Duplicate Rule flagging the record. Anexus already avoids the usual cause by upserting rather than inserting — so if you still see it, the org’s Duplicate Rules are blocking even a matched update. Ask your Salesforce admin to set the Anexus Connect app’s Duplicate Rule policy to "Allow Save".
REQUEST_LIMIT_EXCEEDED
The org has spent its 24-hour API allowance. It is rarely us that spent it — a data load or another integration usually did — and there is nothing to fix on either side. The counter rolls forward, the affected contacts stay pending, and the next Sync past contacts pushes them.
The connection worked, then quietly stopped
Salesforce access tokens expire after about an hour and are refreshed automatically with the refresh token, so expiry alone should never be visible to you. A refresh token itself stops working when someone blocks the app under Connected Apps OAuth Usage, when the Connected App’s refresh token policy expires it after a period of inactivity, when the user’s password is reset under some org policies, or when the sandbox you connected was refreshed. Click Test on the Salesforce card — if it fails, disconnect and connect again.
Disconnecting, and revoking on the Salesforce side
Click Disconnect in Anexus and we stop writing immediately. To revoke the authorization inside Salesforce as well: Setup → Connected Apps OAuth Usage, find Anexus Connect, click Block.
Contacts already written stay in your org. Disconnecting stops future writes; it does not reach back into Salesforce to delete anything.
Notes for Salesforce admins
Anexus accesses the org with the standard api and refresh_token OAuth scopes, and touches only the Contact object. No data leaves your org without the authorizing user’s explicit consent. Every API login is auditable in Setup → Login History, filtered by Application = Anexus Connect.
The settings that decide whether your users can connect at all live in Setup → Apps → Connected Apps → Manage Connected Apps → Anexus Connect → OAuth Policies. Three matter: Permitted Users (all users, versus admin-approved only — the second requires you to assign a profile or permission set first), IP Relaxation (relevant if your profiles enforce Login IP Ranges, since API calls arrive from our servers rather than your offices), and the Refresh Token Policy — set it to expire on inactivity and connections will die on their own after that window.
A least-privilege setup is a permission set granting API Enabled plus Create and Edit on Contact, assigned to the people who actually carry Anexus cards. Nothing here has any reason to involve Modify All Data.