The mobile app is where field work happens: a branded iOS and Android app carrying your name, your mark, and your forms. Field users sign in, fill forms, and submit — with or without signal.
Sign-in and first sync
Users sign in with the credentials they were invited with. A sync runs automatically on sign-in, so published forms and the data sources they reference download before the user touches anything — no manual refresh needed on a fresh install. After that, sync runs at sign-in, right after a record is submitted, and when the app is opened with records still waiting to upload. Tapping the sync icon runs the whole exchange on demand: published forms and data-source updates come down, queued records go up.
A user who has forgotten their password can tap Forgot your password? on the sign-in screen after typing their email. The reset link arrives by email and opens in the phone's browser, where they set the new password and then return to the app to sign in. Workspaces that sign in through their own identity provider do not show the link, since those accounts have no FieldScroll password.
Filling a form
The Forms screen lists the published forms assigned to the user. Opening one walks through its fields — and the app captures more than typed answers:
- Photos — from the camera or the photo library, compressed on device before upload. A photo is resized to fit inside 1,920 by 1,920 pixels, measured on its longer edge, so a photo taken with the phone upright ends up the same size as the same shot taken sideways. A photo already smaller than that is left as it is.
- Signatures — drawn on screen with a finger.
- Location — a GPS point with accuracy metadata, captured when the form asks for it.
- Barcodes — scanned with the camera into text fields configured for scanning.
- Files and video — attached through the device's picker when a form allows them.
Conditional fields show and hide as answers change, and formula fields calculate on the spot — the same behavior described in forms.
A multi-select shows the choices that were picked when it is closed, not a count of them, so a filled form can be checked without reopening each field. A choice that is no longer offered still shows if it was captured.
A repeating section asks before it removes a row, whether or not the row has anything in it yet. Its Add button stays in the same place in the section header however many rows there are, and Done on an open row brings the section back into view.
A lookup field opens a searchable list of rows from its data source. Long lists load as the user scrolls, and a line above the list reads how many rows are shown out of how many match — "Showing 100 of 512 — search to narrow" — so the size of the list is never a guess. Both the list and the search read the device's own copy, so they work with no signal. When a lookup's filters have to be calculated from other answers, the app works from the first 2,000 matching rows and says so rather than showing a short list as if it were complete.
What blocks a submission
On a form split into pages, each page button carries a count of the required fields on that page that are still empty, so a user can see where the remaining work is before pressing anything. The count goes down as the form is filled. Fields the user cannot fill — calculated and read-only ones — are left out of it, and a field that sits outside every page counts toward every page, since it shows on all of them.
Pressing Submit checks every visible field against the rules the form sets. When something is missing or wrong, the app shows a Check these fields list naming each field and what is wrong with it, and the page bar switches from the plain remaining count to a red count of the pages holding a problem. The two counts answer different questions: how much is left, and what is wrong.
Required fields inside a repeating section are checked too, and the list names the row: "Evaluations, row 3: Variety: Please select an option". A collapsed row shows a count of its problems on its header, so a long list of rows does not have to be opened one at a time. A required repeating section with no rows at all asks for one, and a required lookup with nothing selected asks for a selection.
A hidden field is never checked, including a required one — see form logic.
Opening a form by scanning a code
A QR code stuck on a machine, a vehicle, or a door can open the app straight to one form, with fields already filled in — the asset's make and model, or a whole row from a data source. The person scans with their phone's camera and lands on the form, skipping the hunt through the Forms list and the retyping of details already printed on the label.
This is a different thing from the barcode capture above. A barcode field reads a code into an answer while the person is already filling a form; a scanned FieldScroll code is what opens the form in the first place. Both can appear on the same job.
You create the codes yourself: FieldScroll does not print them. You build a URL in the documented format and encode it with your own labelling tool, which is what makes it practical to produce one code or ten thousand from an asset list. The format, the values to put in it, and what happens when a code cannot be used are covered in QR codes and deep links.
Scanning works offline once the form and any data source it reads have synced to the device. If the person is signed out when they scan, the app holds the request, and opens the form once they sign in.
Subforms — the repeating rows in a form — appear one of two ways, set by the form builder. Most expand in place. A subform set to a dedicated screen opens each row on its own full screen instead, with an add button for the next row and a done button to return to the main form. Either way the captured values are the same; only the layout differs.
Some forms are split into pages — sections the builder groups behind a bar of buttons pinned above the form. Tap a button to move to that section; the bar scrolls sideways when there are more pages than fit the screen. A form that puts every field on a single page shows no bar — it reads as one long form. While filling, each button shows how many required fields on that page are still empty. When you try to submit and something is missing or wrong, that count turns into a red count of the problems on the page and jumps you to the first one, so you never hunt across sections for the field to fix. The Contents list — the in-form jump menu — groups its entries by page and marks the one you are on. A dedicated subform screen can carry its own page bar for the fields inside a row.
Offline drafts and auto-save
Every record in progress is a draft stored in an on-device database. Drafts survive app restarts, phone reboots, and days without signal.
The app saves work three ways without being asked: 30 seconds after the last change, the moment the app goes to the background, and when the user navigates away from the form. A ringing phone or a dead battery does not cost a half-finished inspection. Leaving a form saves it the same way whether the user presses the back button, swipes back, or uses the phone's own back gesture. If that save cannot be written — a full device, most often — the app says so and keeps the user in the form rather than closing it and losing the recent edits.
Submitting and syncing
Pressing Submit queues the record for upload and, when the phone has a connection, starts that upload immediately in the background. If the phone is offline, the record waits and goes up the next time the app is opened with a connection. The sync icon in the header carries an amber dot for as long as anything is still waiting, so a user can tell at a glance whether their day's work has left the phone.
The Records screen shows everything on the device with its current status — draft, submitted, synced, or error — and can filter by status and sort newest or oldest first. A submitted record shows an upload-pending cloud icon rather than a checkmark, because submitted means queued, not delivered. Once a record and all its media reach the platform, it shows as synced and appears in the dashboard for review.
A record that is submitted but has not uploaded yet can still be fixed. Opening it shows an "Unlock to edit" button that returns the record to a draft, so a field user can correct an accidental submit before it leaves the device. Once a record has synced, it can no longer be unlocked this way. See record statuses for the full list.
If an upload fails after repeated attempts, the record is marked with an error rather than discarded — the captured data stays on the device. The mechanics of queuing and retry are covered in offline sync.
Older records and form versions
Forms change over time, and the app makes sure every record opens under the right version of its form:
- Compatible older records open under the newest form. If the form changed in a way that keeps old records readable — a field was added, a label was edited — an older record opens under the current form and works like any other.
- Other records open under the form they were captured with. If the form changed in a way that is not compatible — a field's type changed, for example — the record opens under its original version, with a banner explaining that. Nothing is lost or misread.
- Drafts move up. A draft — work not yet submitted — moves to the newest compatible version of its form when opened, so field users always fill the latest form.
- Removed choices stay visible. If a choice was removed from a list after a record was captured, the stored answer still shows, subtly marked as no longer offered. It stays valid until the user changes the answer; from then on, only the current choices are offered.
The reasoning behind compatible and breaking changes is covered in form versions.
Dispatched records
A dispatcher can check an existing record out to a field user from the dashboard — a follow-up visit, a work order for the morning. See dispatching a record for the dashboard side.
On the device, a dispatched record arrives on the next sync with all of its photos and other media already downloaded, so it can be opened and edited with no connection. It appears on the Records screen like a draft, and opening it shows a banner: "Dispatched to you", with the due date if one was set. The user edits it like any draft — auto-save and offline behavior are the same — and presses Submit when done. The upload sends the updated record back and ends the checkout.
If the dispatcher takes the record back before the user submits, the next sync recalls it. The app shows a short notice — for example, "1 record was recalled" — and the local copy becomes read-only: the user can still open and read it, or delete it, but it will not upload. The Records screen's status filters include Dispatched and Revoked, so recalled copies are easy to find and clear out.
Text size and screen preferences
App text follows the phone's own text-size setting, so a user who has raised it in iOS or Android settings sees larger text here as well. This is the answer for a crew member who finds the app hard to read in daylight or without their glasses — it is set per person on their own phone, and nothing has to change on the form.
The Forms screen remembers whether the user chose grid or list, which collection groups they collapsed, and how each list is sorted. Those choices survive leaving the screen, closing the app, and signing out. Status filters on the Records screen deliberately do not stick: a filter hides records, and a filter left on from days ago reads as missing work rather than as a setting.
Support screen
The Support screen shows your workspace's support contact. One tap opens an email to that address, and the screen displays the workspace's instance identifier — asking users to mention it speeds up any support conversation. You set the support address in instance settings.