A one-way, read-only connection: noombat reads your CRM on a schedule and never writes anything back. A Salesforce admin can complete this in about 20 minutes.
Using HubSpot instead? HubSpot setup guide →
A dedicated account keeps noombat's access separate from any person — auditable on its own, unaffected by staff changes, and revocable in one click.
Setup > Users > New Userintegrations@noombat.ai — we monitor this inbox and handle the verification emails, so nothing lands on your plate.About the welcome email
The Integration user licence needs a companion permission set licence before CRM objects can be granted to it. Skip this and step 3 fails with “The user license doesn't allow the permission: Read Accounts”.
Setup > Users > (the noombat user) > Permission Set License Assignments > EditTick “Salesforce API Integration” and save.
“This licence allows Modify All Data — is that safe?”
Setup > Permission Sets > NewSystem Permissions
Object Settings — Read + View All on each, no Create, Edit or Delete
Account | the companies you sell to |
Contact | the people at those companies |
Lead | not-yet-qualified prospects |
Opportunity | pipeline and revenue outcomes |
OpportunityContactRole | who was involved in each deal |
RecordType | how you classify records |
Campaign | optional — if you track campaigns |
CampaignMember | optional — campaign membership |
Field-level security: Read on all fields of the above — and if any field is sensitive, exclude it and we simply won't receive it.
Why “View All”, not just Read
Four objects you won't find in Object Settings — that's normal
Finally, assign the permission set to the noombat user: Permission Set > Manage Assignments > Add Assignment
This registers noombat as an application in your org and produces the Consumer Key and Secret we connect with. (Salesforce no longer allows creating classic Connected Apps — External Client App is the current mechanism.)
Setup > External Client App Manager > New External Client Apphttps://noombat.ai/api/oauth/salesforce/callback (required by the form; never actually used in this flow)(api)” — exactly this one.Watch out for the scope lookalike
sfap_api (“Salesforce AI Platform API”). It looks like the right one and isn't — with it, the connection authenticates but every data query fails with INVALID_SESSION_ID. The one we need is the plain api scope. Please also leave full unchecked; we don't need it.Then, after saving — two easy-to-miss settings:
(the app) > Policies > OAuth Policies — tick Enable Client Credentials Flow and set the noombat integration user as the Run As user.(the app) > Policies > Permitted Users > Manage Permission Sets — add the noombat Read-Only permission set, so the pre-authorization actually includes our user.Einstein Activity Capture stores captured emails and meetings outside the Salesforce database, where no API can read them. One setting brings the emails back in reach:
Setup > Einstein Activity Capture > SettingsEnable “Sync Email as Salesforce Activity” — captured emails then become real Task/EmailMessage records that reports, automations and noombat can read.
Calendar meetings captured only by Einstein remain outside the API — meetings logged as Salesforce Events (by reps or a booking tool) are read normally. If most of your meetings live only in Einstein, tell us and we'll plan around it together.
yourco.my.salesforce.com)(the app) > Settings > OAuth Settings > Consumer Key and Secret. Salesforce emails you a verification code first, then reveals both values to copy.Share the secret securely — never in a plain email
integrations@noombat.ai. Also good: a self-destructing link (e.g. onetimesecret.com — paste the value, send the link, it burns after one view). Or read it out on a call. If the secret ever leaks, you can rotate it in the app settings at any time and the old one dies instantly.Once the details arrive we run a read-only verification the same day — connecting as the integration user and checking each object returns what it should — and confirm back to you. If anything's off, we tell you the exact setting to adjust; the table below is the complete list of what it could be.
Every error below is one we've met in real setups, with the exact fix. If yours isn't here, send it over — we diagnose these quickly.
| What you see | Why | Fix |
|---|---|---|
| “Can't assign permission set… The user license doesn't allow the permission: Read Accounts” | The user doesn't have the “Salesforce API Integration” permission set licence yet. | Step 2 — assign the permission set licence on the user first, then assign the permission set. |
| Account, Contact and other CRM objects don't appear in the permission set's Object Settings | The permission set's License field is set to “Salesforce Integration” (the user licence) or the wrong entry. | Step 3 — recreate the permission set with License = “Salesforce API Integration”. |
| Task, Event, User or EmailMessage don't appear in Object Settings | Expected — these aren't normal objects in Salesforce's permission model. | Step 3 — their access is derived; see the “four objects you won't find” box. |
| invalid_grant — “no client credentials user enabled” | The Client Credentials flow isn't enabled on the app, or no Run As user is set. | Step 4 — OAuth Policies: enable Client Credentials Flow and set the integration user as Run As. |
| invalid_app_access — “user is not admin approved to access this app” | The app is (correctly) restricted to pre-authorized users, but the integration user isn't on its list. | Step 4 — Policies → Permitted Users → Manage Permission Sets → add the noombat permission set. |
| Token works, but every query fails with INVALID_SESSION_ID | The app has the wrong OAuth scope (usually the “sfap_api” lookalike), or “API Enabled” is missing. | Step 4 — scope must be “Manage user data via APIs (api)”. Step 3 — tick “API Enabled”. |
| Queries work but record counts are a fraction of what you'd expect | “View All” is missing on some objects, so sharing rules silently filter what the user sees. | Step 3 — tick View All (not just Read) on each object in the list. |
The questions security-conscious admins ask us, answered the way we answer them.
Yes, and it's enforced by Salesforce, not by our promise. The permission set grants Read only — no Create, Edit or Delete on any object — so the platform itself rejects any write attempt. We also ask you not to grant “Modify All Data” or “View All Data”.
No. That list is a catalogue, not a grant. Salesforce's documentation states it directly: “For users to access additional license functionality, they must both be assigned the permission set license and a permission set containing the feature permissions.” The licence alone grants nothing — the user has only what your permission set enables, and yours enables Read + View All and nothing else. You can verify on the user record: Modify All Data appears nowhere.
Accounts, contacts and leads (who you sell to), opportunities (pipeline and revenue), and sales activity — calls, meetings, emails logged on those records. noombat keeps a read-only mirror and uses it to score your market, connect the leads it generates to the activity and revenue they produce, and show your team a live, prioritised view. Historical data matters too: the scoring learns from what already happened, which is why a forward-only feed (like a webhook) isn't enough.
Yes. Field-level security stays entirely in your hands: exclude any field from the permission set's field permissions and we never receive it. The integration works fine without non-essential fields.
Usually nothing. Enterprise, Unlimited and Performance editions include five free “Salesforce Integration” user licences (API-only users, made for exactly this); beyond five they're about $10 per user per month. Professional edition doesn't include API access — it's a paid add-on there, so talk to us before setting up and we'll figure out the best route together.
A webhook works well for pushing one object's changes in real time, but it can't replace API access here: webhooks only send changes going forward (noombat needs the existing history to learn from), each object needs an automation built and maintained on your side, and to fetch the full record a webhook receiver ends up calling the API anyway. We're happy to add webhooks on top of API access for time-sensitive events later.
Instantly, from your side, in either of two ways: freeze (or deactivate) the integration user, or revoke the External Client App. Access ends immediately and nothing on our side can restore it. If the Consumer Secret is ever compromised, you can also rotate it in the app settings at any time.
Yes. Every API call runs as the single dedicated integration user, so your login history and event logs show exactly what was read and when, attributable to noombat alone. The account has no UI access — the “Salesforce Integration” licence is API-only, so there's no password to phish and no screen to look at.
In an isolated per-client database schema hosted in the EU (Frankfurt), encrypted in transit and at rest, never mixed with other customers' data, and deleted if we part ways. We're happy to put data-handling terms in writing or walk through it with your security team.
Anything unclear, or a policy conflict? integrations@noombat.ai — or bring your Salesforce admin and we'll do the whole thing together on a call.