FieldScroll connects to Salesforce in two directions, and you can use either one on its own.
- Salesforce into FieldScroll. A data source can mirror one Salesforce object. Field users pick from those records in a lookup field, on a phone, with or without signal.
- FieldScroll into Salesforce. A webhook subscription can write each submitted record into a Salesforce object as it lands, creating a new record or updating one that matches.
Both are set up from the dashboard by an org admin or form admin. Nothing is installed in your Salesforce org, and there is no package to deploy. You sign in, and FieldScroll works through the Salesforce API as the user who signed in.
What you need in Salesforce
- A Salesforce user whose profile allows API access. Developer Edition, production, and sandbox orgs all work.
- That user's permissions decide what FieldScroll can see and do. If the user cannot read a field, the field does not appear in the wizard. If the user cannot create records on an object, deliveries to it fail with a Salesforce permission error. A dedicated integration user with exactly the access you intend is the tidiest setup.
- Room in your org's daily API request limit. Every sync of a mirrored object and every delivery to Salesforce spends requests against it. The sync interval is the main dial.
Connecting
Every Salesforce data source and every Salesforce destination holds its own connection, made in its wizard's Connect step.
- Say whether the org is a production or Developer Edition org or a sandbox. Sandboxes sign in through a different Salesforce address, and tokens from one do not work against the other, so this choice has to be right.
- Choose Connect to Salesforce. A Salesforce window opens. Sign in there, and approve the access request if Salesforce asks.
- The window closes on its own and the wizard moves on.
You type your password on Salesforce's own page. FieldScroll never sees it. What Salesforce hands back is a pair of access tokens, which FieldScroll stores encrypted and never shows in the dashboard. FieldScroll refreshes those tokens itself as they expire, so a connection keeps working until someone revokes it in Salesforce, the user's password policy invalidates it, or a sandbox refresh changes the org's address. When that happens, see reconnecting.
If nothing opens, your browser blocked the popup. Allow popups for the dashboard's address and try again.
To cut off FieldScroll's access from the Salesforce side, revoke the FieldScroll app under the connected user's OAuth usage in Salesforce Setup. Deliveries and syncs from that connection then fail until someone reconnects.
Salesforce records in a lookup field
Create the source from Data sources → New → Managed (Salesforce). The wizard connects, lets you pick an object, then lets you pick the fields to mirror and how often to sync. Data sources walks through each step, the field types that cannot be mirrored, and how field names become column keys.
Once the first sync lands, the source behaves like any other data source. Build a lookup field on it, publish the form, and the rows reach every device that has the form, where they are searchable offline. Records changed in Salesforce arrive on the next sync. Rows are read-only inside FieldScroll: editing happens in Salesforce.
Choosing a sync interval
Each sync reads the whole object again. The default is every 60 minutes and the shortest allowed is 15. For reference data that changes a few times a day, such as sites, assets, or customers, an hour is usually right. A short interval on a large object spends your org's daily API budget quickly and gains little, since field users only see new rows after their device's next sync anyway.
Sync now on the source's page runs a sync immediately when you have just changed something in Salesforce and do not want to wait.
How big an object can be
A source mirrors up to 100,000 records. Past that, a sync reads the first 100,000 and stops, and the source shows Needs attention with the reason. New and changed rows still arrive; deletions are skipped, because a partial read cannot tell what was removed. If the object you need is larger, mirror a narrower one, or ask your Salesforce admin for a filtered view of the data as its own object.
When Salesforce changes
Fields removed in Salesforce are kept in the source until no published form uses them. New fields are not added on their own. A mapped field whose type changes stops the sync and asks you to re-map it. The reasoning is in data sources.
Pushing records into Salesforce
Create the subscription from Webhooks → New, choose Salesforce as the destination, and connect. Then:
- Pick the events. Usually
record.created, filtered to the form whose submissions belong in Salesforce. The full list is in webhooks. - Pick the object the records should land in. The wizard lists the objects the connected user can create records on.
- Map the fields. Each Salesforce field you want filled gets a template.
{data.field_values.site_id}copies one form field;{timestamp}copies when the event happened; a template can mix text and placeholders, likeInspection {data.field_values.site_id}. Fields Salesforce requires are marked, and the wizard warns until each one has a template. If the form's shape does not match what Salesforce wants, a preprocessing script can reshape the event first. - Choose insert or upsert. Insert creates a new Salesforce record for every event. Upsert updates the record whose external id matches and creates one when nothing matches; it needs a field on the object that Salesforce has marked as an external id, and the wizard only offers those.
Use Send test event before real traffic. Then watch the subscription's delivery history: each delivery shows whether Salesforce accepted it and, when it did not, Salesforce's own error text.
Deliveries retry the same way every webhook does, three attempts with a growing delay. With insert, a retry after a failure that happened after Salesforce created the record would create a second one. That is rare, but if duplicates would matter, upsert on an external id is the safer setting.
Files attached to a record, such as photos and signatures, are not sent to Salesforce yet. The delivery carries the record's field values and metadata only.
Reconnecting
A connection stops working when Salesforce revokes or expires the tokens, or when a sandbox refresh gives the org a new address. Both a source and a destination tell you plainly:
- A data source shows Error in its sync panel with a message that ends in "Reconnect the data source", and its Reconnect Salesforce button is highlighted. Choose it, sign in again, and the source stores fresh tokens and runs a sync.
- A webhook subscription shows failed deliveries whose error mentions an invalid or expired session. Open the subscription, choose Reconnect in its Salesforce settings, sign in, and save. Failed deliveries that are still within their retry attempts go through on their next try; ones already marked failed need to be re-sent from your side.
Troubleshooting
Messages a data source shows in its sync panel:
| Message | What it means | What to do |
|---|---|---|
| Salesforce connection expired or was revoked | The stored tokens no longer work | Reconnect |
| Salesforce daily API request limit reached | Your org spent its 24-hour request allowance | Sync resumes at the next interval once the limit resets. Lengthen the interval, and check what else in the org is using the API |
| The Salesforce object no longer exists or is not accessible to the connected user | The object was removed or renamed, or the user lost access | Restore access, or create a new source on the right object |
| A mapped Salesforce field is no longer accessible to the connected user | Field-level security changed, or the field was renamed | Restore access, or re-map the source's fields |
| Salesforce field type changed | A mapped field now holds a different kind of value | Re-map the field in the source's settings |
| The connected Salesforce user lacks read access to this object | Profile or permission set does not include the object | Grant read access to the integration user, then Sync now |
| Snapshot truncated at 100000 rows | The object holds more records than a source can mirror | See how big an object can be |
Messages a webhook delivery shows in its history come straight from Salesforce, prefixed with Salesforce's error code. The common ones:
| Salesforce code | What it means | What to do |
|---|---|---|
REQUIRED_FIELD_MISSING | A required field on the object had no value | Map the field, or give it a fixed value in the template |
FIELD_CUSTOM_VALIDATION_EXCEPTION | A validation rule in your org rejected the record | The message names the rule; adjust the mapping or the rule |
DUPLICATES_DETECTED | A duplicate rule in your org matched an existing record | Switch to upsert on an external id, or relax the rule for the integration user |
STRING_TOO_LONG | A mapped value exceeds the field's length | Shorten the value with a preprocessing script, or map a shorter field |
INVALID_FIELD or INVALID_FIELD_FOR_INSERT_UPDATE | A mapped field does not exist, or cannot be written by this user | Re-map, or grant edit access |
INSUFFICIENT_ACCESS_OR_READONLY | The user cannot create or edit records on the object | Grant create and edit access to the integration user |
INVALID_SESSION_ID or invalid_grant | The connection expired or was revoked | Reconnect |
REQUEST_LIMIT_EXCEEDED | The org's daily API allowance is spent | Deliveries retry on their own; lengthen sync intervals if a mirrored object is the main consumer |
What is not there yet
- Record attachments are not pushed to Salesforce.
- Salesforce cannot start a FieldScroll dispatch on its own. Assign work from the dashboard or the API.
- There is no two-way sync of a single record. A mirrored object flows one way into FieldScroll, and a destination flows one way into Salesforce.
- A Salesforce source cannot be created from the API alone. The API accepts the source definition, but the sign-in that produces its tokens only happens in the dashboard.