Salesforce

Connect Salesforce once and your allme customers keep their own contact details current on your Salesforce contacts. No admin procedure and no code — authorize the app and the fields map themselves.

Before you start

A Salesforce production or developer org. Sandboxes are not supported — they sign in at a different Salesforce host.
A Salesforce user with the Customize Application permission, as well as read and edit on contacts — a System Administrator profile carries it. This is the user you authorize with, and the whole sync then runs as them.

Why that permission, and what happens without it. You prepare no fields by hand: the integration creates every custom field it needs, and creating a field in Salesforce needs the metadata permission above. A user with contact access alone will finish the authorization cleanly and then hit a refusal the first time a field has to be made — your status page shows Salesforce's own message. Reconnecting as a user who holds the permission fixes it.

Setting it up

Open the allus portal — Configuration → Integrations.
Step 1 — connect allus. Click Connect next to Salesforce. This creates the service your customers connect to (alerts go to your allus account's own email), its data client and its webhook — nothing to paste — and hands you to this integration's own setup page.
Step 2 — connect Salesforce. You are sent to Salesforce to authorize the app, and back to your status page when you approve. That is the last step: syncing starts on its own.

The app holds the service key on your behalf. That is what lets it read what your customers share. It is stored encrypted and is never shown in your allus portal.

Which Salesforce user you connect as matters. The sync runs on that user's own permissions and sharing, so connect as someone who can see and edit contacts. If that user is deactivated, or the app's access is removed, your status page shows it and reconnecting is one click.

One thing your customers must share

Salesforce will not create a contact without a last name, so the integration marks that field required on your service. Anyone connecting from now on has to map a real field to it — they cannot skip it and cannot answer it once-off.

Nothing is invented and nothing is lost. A customer who connected earlier, or who declined a later request, can still arrive without a last name. The integration will not make one up and will not create a half-record: it holds what they did share and creates the contact the moment a last name arrives.

It is also the one field a withdrawal cannot empty. Salesforce refuses to hold a contact with no last name, so if a customer stops sharing theirs the name stays on the contact and a task records that they withdrew it. Every other field is emptied — see what happens after that.

Where each field lands

What your customer shares	Where it appears in Salesforce
First name, last name	First Name and Last Name
Email	Email
Phone	Phone
Address	The contact's mailing address — street, city, state, postal code and country
Anything else your service asks for	A custom contact field named allme_<field>, labelled with your own request-field label

One further custom field, allme_id, holds the customer's share code and is how the integration finds the same contact again. Every field the integration creates counts towards your org's own custom-field allowance, and none is ever removed — disconnecting leaves your fields and their values exactly as they are.

Documents never become fields. Photo, document and legal-document fields are excluded from mapping entirely — no document bytes reach Salesforce.

If a field is created but not visible to you. Creating a field and being allowed to write it are two different things in Salesforce. The integration checks, and where the connected user cannot write a field it says so on your status page instead of failing quietly — grant that field to the user in Setup and it starts syncing on its own, with the values that were waiting.

How an existing contact is matched

When someone connects for the first time, the integration looks for them in this order: the allme_id field, then an exact email match, then an exact phone match. If a step finds more than one contact, it moves on rather than guessing — and if nothing matches uniquely, a new contact is created.

Why a duplicate is preferred to a guess. Merging two contacts in Salesforce is easy; discovering that one customer's details were written onto another customer's record is not. Ambiguity therefore never adopts.

Phone matching is exact. Salesforce stores phone numbers as free text, so a contact is matched on phone only when it holds the number in the same full international form. Where it does not, a new contact is created rather than the wrong one adopted.

What happens after that

Edits arrive within seconds. When a connected customer changes a shared field, the Salesforce contact updates.
Withdrawing a field clears it and logs a completed task on the contact saying which field was withdrawn — with one exception: last name stays on the contact, because Salesforce will not hold a contact without one. The task says so in that case, so the record still tells you the customer stopped sharing it.
Ending a connection leaves the contact intact and logs a task. Nothing is deleted or blanked.
Sync is one-way. Editing the contact in Salesforce never changes your customer's allme profile; the next update from them simply overwrites it again.

Notes appear as completed tasks on the contact's activity timeline rather than in the Notes list. That is deliberate: a task can carry the integration's own key, which is what guarantees an interrupted sync updates the same entry instead of leaving you a duplicate.

Documents and contract flows on the timeline

When your company shares, updates or removes a document for a customer, when the customer signs it, or when they complete a contract flow with your company, the event shows up on their contact's activity timeline as a completed task naming what happened and when — automatically, with no setup. No document bytes ever reach Salesforce — only the fact that something changed.

These tasks share the same key as every other note the integration writes, so an interrupted sync updates the same entry instead of leaving you a duplicate.

Limits worth knowing

Your Salesforce API allowance is respected. Salesforce meters one request allowance for your whole org, shared with everything else you have connected. The integration paces itself well inside it and backs off when the allowance runs out, picking up where it left off — nothing is lost.
Sandboxes are not supported — connect a production or developer org.
An org that has removed the standard Completed task status will refuse the task entries; that shows on your status page as a refused change.

If something looks wrong

Your status page carries a sync-health card naming the affected customer and what to do — usually reconnect, or finish the setup steps when a field is waiting to be granted. It also shows the field mapping, how many changes are waiting, and the switch between having changes pushed to the app or fetched on a schedule.

CRM integrations overview · How the connection model works · Portal guides

Start here

Build

CRM integrations

Portal

Reference