Salesforce data access and permissions

What Mobly reads from your Salesforce org, what it writes, which permissions the connection needs, and what you control. Written for the security or IT review that usually accompanies a Salesforce integration.

For the step-by-step connect walkthrough, see the Salesforce setup guide.

Overview

Mobly connects to your Salesforce org to keep Lead, Contact, and Account records in sync with the activity captured at your events — badge scans, conversations, meetings booked, and follow-up logged through Mobly.

The connection is built on Paragon, a third-party integration platform that manages the secure OAuth connection to your org. Mobly's own workflows run on top of it and do not store your Salesforce credentials directly.

The integration performs three functions:

1. Writes new or updated Lead, Contact, and Account records in Salesforce based on activity captured in Mobly

2. Reads existing Salesforce records to avoid creating duplicates, and to pull relevant account and deal context back into the Mobly platform for your team

3. Logs activity — scans, notes, calls, emails, meetings booked — as Salesforce Tasks tied to the relevant Lead or Contact

Data written into Salesforce

Object	Action	Trigger
Lead	Create or update	New scan/contact captured with no existing match
Contact	Create or update	New scan/contact captured, matched or created under an Account
Account	Create (only if no match found) or update	New company encountered; company-level fields synced from Mobly
Campaign Member	Create or update	Event/campaign attendance status changes in Mobly
Task	Create	Activity logged in Mobly (scan, note, call, email, meeting booked, social interaction)

For the subject and description format Mobly uses on each activity type, see Finding Mobly activities in your CRM.

Duplicate prevention. Before writing, Mobly checks for an existing match — first by Salesforce record ID (if already known), then by email address, then by company name or website domain. Only then does it create a new record. This is what keeps Mobly from generating duplicate Leads, Contacts, and Accounts.

Field-level scope is yours to set. Exactly which Salesforce fields receive which Mobly data is configured per customer during setup, so the mapping fits the fields already in your org — including whether Mobly may overwrite a field that already has a value. See Field mapping and Write behavior.

Data read from Salesforce

Mobly reads:

• Lead, Contact, and Account records — to check for an existing match before writing (duplicate prevention)

• Account records, together with related Opportunities and up to two related Contacts, plus the record Owner's name — used to surface account and deal context inside Mobly for your team

• Campaign records — to confirm a campaign exists before logging attendance against it

• Campaign Member records — to check existing engagement status before updating

After every Lead or Contact write, the resulting record log is sent back to Mobly to confirm the sync succeeded.

If a write fails, the error Salesforce returns (which can include record identifiers) is sent to Mobly's Reconciliation page for troubleshooting.

How Mobly uses your Salesforce data

This applies to everything the integration reads, writes, or sends back — record matches, account and deal context, sync confirmations, and error details:

• Used only to run the integration — keeping records in sync, and presenting attribution and deal value alongside event activity inside Mobly

• Not used for enrichment — your Salesforce data is not used to enrich Mobly's own data

• Not shared — your Salesforce data is not shared with any other organization

Salesforce permissions required

The Salesforce user connected to the integration needs:

Access	Objects
Create, read, update	Lead, Contact, Account, Campaign Member, Task
Read only	Opportunity, Campaign, User (Owner name only)
Customize Application / Metadata deploy	Needed once, during initial setup, to create the custom fields listed below

Field-level security must also be open on every field in your Mobly mapping — profiles or permission sets that lock down a mapped field cause Mobly to silently skip it.

Because the specific standard and custom fields synced are configured per customer during onboarding, the exact field-level footprint depends on what your team maps in setup.

Use a dedicated integration user. A Salesforce service account owned by IT — rather than credentials tied to an individual employee — keeps the connection alive through team changes. If the connected user is later deactivated or loses API Enabled, syncing stops.

Secondary connections request the same permissions

If you connect Salesforce as a Secondary integration alongside a primary CRM, it requests the same permission set as a primary connection — there's no reduced or read-only scope, even though Secondary only reads data today. See Connecting a secondary CRM integration.

OAuth scopes

The connection is established via OAuth. Mobly does not store your Salesforce password. Scopes requested at connection time:

Scope	What it's for
api	Programmatic access to query, create, and update Salesforce records and metadata — this is what powers the read/write behavior above
refresh_token (offline access)	Keeps the connection alive without requiring your admin to re-authenticate manually
id, profile, email, address, phone	Standard Salesforce identity scopes that identify the connected admin user (name, username, email) at the time of authorization

Identity scopes don't widen data access. id, profile, email, address, and phone identify the connecting user only — they don't grant access to other users' or contacts' records. Access to your org's data is governed by the api scope together with the connected user's own object- and field-level permissions.

Custom fields Mobly adds

During setup, Mobly offers to create a set of custom fields on the Lead and Contact objects (the same fields on both) to store Mobly-specific data — scan history, event attendance, and enrichment data.

These are additive only. They do not modify or remove any existing field in your org.

Field	Purpose
Mobly ID	Mobly's internal record identifier
Mobly Description	Enrichment summary
Mobly LinkedIn	Individual's LinkedIn URL
Mobly Individual Address	Individual's address
Mobly Profile Picture	Profile photo URL
Mobly Other Phone Numbers	Additional phone numbers
Mobly Company LinkedIn	Company LinkedIn URL
Mobly Company Street / City / State / Zip / Country	Company address, broken out by field
Mobly Number of Scans	Count of times scanned
Mobly First Scanned By / Mobly Last Scanned By	Rep who first / last scanned this person
Mobly Last Scanned Event	Most recent event scanned at
All Scanned Events	History of events scanned at
Mobly Events	Events associated with this record
Most Recent Mobly Label	Latest label applied in Mobly
All Mobly Labels	Full history of labels applied

Exact Salesforce API names can be confirmed in your org's setup once the fields are created, or from your Mobly implementation contact.

Creating these fields is optional — skip the step during setup and map Mobly data to fields you already have instead.

Configuration and customer control

Several aspects of the integration are set collaboratively with your Mobly implementation contact, and are adjustable at any time:

• Sync mode — Lead + Contact, Lead only, or Account/Contact only. See Choose a sync mode

• Field-by-field mapping between Mobly data and your Salesforce fields, including whether Mobly may overwrite a field that already has a value. See Field mapping and Write behavior

• Whether Leads with no captured email address are created at all. See Send Leads With No Emails

• Address formatting — whether the address arrives as one string or split into components, and whether state and country render as codes or names. See Address formatting

• Which specific standard and custom fields receive which data

Questions or changes

Reach out to your CSM, or contact [e-mail].

Related articles

• Salesforce setup guide — the connect walkthrough

• Finding Mobly activities in your CRM — per-activity object and template reference

• Field mapping

• Write behavior — per-field overwrite control

• Reconciliation — where sync failures surface

• Fixing Salesforce sync errors