Forms can work where the internet does not. The recipe: a fillable PDF with a submit button that composes an email, filled out offline on any device, sent automatically when the connection returns, and imported into SharePoint by a profile that reads the attachment and maps its values to your columns. No manual re-entry anywhere. This guide walks the full round trip, from generating the PDF to watching the list item appear.
Offline is not an edge case
The internet feels universal until the day your process meets a basement, a construction site, or an airplane. Field crews inspect equipment in places with no signal. Auditors work in facilities where guest networks are forbidden. Drivers, surveyors, and technicians spend their days precisely where coverage ends.
Web forms remain the right default. They validate, adapt, and save instantly, and nothing here changes that. But a process that only works online is a process with a hole in it, and the people in the hole still generate data. The offline PDF path is the fallback that keeps them in the system: the same structured intake, delayed rather than lost.
The goal, stated plainly: distribute forms users can download to their device, a computer, tablet, or phone, fill out with no connection at all, and submit in a way that lands in SharePoint without anyone retyping a thing.
The round trip at a glance
The architecture has four legs, and each is simple.
First, generate a fillable PDF form. Second, distribute it to the people who need it. Third, the user fills and submits offline; the submission is an email that waits in their outbox until connectivity returns. Fourth, an import profile reads the arriving email, extracts the values from the attached PDF, and writes them into your SharePoint list.
The elegant part is the transport. Email is the one channel every device already queues offline. By making the PDF's submit button compose an email, the form inherits store-and-forward delivery for free. No app, no sync framework, no custom infrastructure. The outbox is the sync framework.
Generating the form
Any fillable PDF works, but the Print component closes the loop inside the platform: it generates the fillable PDF from your SharePoint data and layout.
Better still, an action automates the distribution. The action generates the PDF and emails it to the user, and because it is generated per recipient, it can carry preliminary data: the technician's name, the asset's details, last month's readings. The user changes any value as needed and fills in the rest. Pre-filling matters doubly offline, where every value the user does not type is a transcription error that cannot happen in a place where nobody can double-check.
The submit button is the whole trick
The key part of the construction is a custom submit button inside the PDF. It does not post to a server, because there may be no server in reach. It composes an email, with the address and subject set in advance through a mailto URL:
mailto:forms@YOURORGANIZATION.com?subject=IMPORT CUSTOMER CONTACT
When the user clicks the button, their email client opens a new message with the PDF automatically attached and the designated subject line already in place. Offline, the message simply sits in the outbox. The moment the device reconnects, it sends on its own. The user's entire obligation is one click, and the system tolerates hours or days between filling and sending without anyone managing it.
Two finishing touches improve the form. Add a Clear button, as shown in the video, so the same PDF can be reused for new submissions again and again. And tell users, once, that the email may not leave immediately, so a full outbox on a remote site reads as normal rather than broken.
The import profile: where SharePoint takes over
Now the receiving side. In Ultimate Forms, create a new import profile using the Import from an editable PDF attachment option.
Upload your form to the profile, and it automatically detects the PDF's form elements. Map each one to the matching column in your SharePoint list: name to name, date to date, reading to reading. The mapping is the only place the PDF world and the SharePoint world need to agree, and you configure it once.
Then the detail that keeps the system honest: set a condition filtering on the subject line text. The subject your mailto URL stamped, IMPORT CUSTOMER CONTACT in the example, is the routing key. The profile only attempts import on emails carrying it, which protects the list from stray messages and, better, lets one inbox serve many forms. Each form type gets its own subject; each import profile filters for its own. The inspection PDF and the contact PDF share an address and never collide.
From arrival onward, the data is ordinary SharePoint data. Alerts fire on it. Actions route it. The field inspection filed from a dead zone on Tuesday shows up on the Wednesday dashboard like any web submission.
The inbox that makes it run
If you do not already have a dedicated address for inbound traffic, set one up. Create a user account with an address like forms@yourorganization.com. It needs only an Exchange license, email only, which is relatively inexpensive month to month.
Keep the address boring and permanent. It will be baked into PDFs that live on devices for years, and the cheapest migration is the one you never need. One address, many subjects, many profiles: the pattern scales as far as your form catalog does.
For the underlying technical foundations of the editable-PDF import, see the companion article, Update SharePoint List Data When You're Offline. And to watch every step performed end to end, the video below shows the process in action:
Testing the loop before the field does
One rehearsal saves a season of support calls. Run the full circle yourself before distributing anything.
Fill the PDF on a phone with airplane mode on. Click submit, confirm the email sits in the outbox, then restore the connection and watch it send. Check the import profile's run, and verify the list item: every value present, every column mapped correctly, dates parsed the way you expect.
Then test the failure paths on purpose. Send an email with the wrong subject and confirm the profile ignores it. Submit the form with a value left empty and decide how the import should treat it. Send the same form twice and choose your duplicate policy, two items, or an update to one, which the import's action types let you pick.
Finally, hand the PDF to one real field user for a week before the full rollout. The question they ask is the instruction you forgot to write. Fix the form once, and the hundred copies that follow inherit the fix.
Where the pattern earns its keep
The shape fits anywhere connectivity is the missing ingredient. Field inspections filed from basements and rooftops. Meter readings from rural routes. Incident reports from vessels and aircraft. Intake forms handed to clients who will fill them at home, on whatever device they own, with no portal account and no login. Contractor reports from sites where your network does not reach and never will.
In each case the alternative was paper, and paper's true cost was never the printing. It was the retyping, the backlog, and the errors introduced at the keyboard by someone reading handwriting. The offline PDF keeps the structure of a form and the reach of paper, and the import profile deletes the retyping entirely. The connection gap stays. The data gap closes.
Frequently asked questions
Add your comment
