Teams that have run iFormBuilder for years usually have two things: a set of forms that encode real operational knowledge, and an integration or two that other people depend on. Neither should be put at risk by a platform change. This page is written for that team. It is not a feature-by-feature comparison, and it makes no claim that one product is better than the other; it says what moves cleanly, what to check first, and how to run both while you decide.
Why teams look at FieldScroll from iFormBuilder
The reasons that come up in conversations, in rough order:
- They want to sell the workflow to their own customers under their own brand, not run it as an internal tool. FieldScroll is built for that offer; see white-label platform.
- They want a record to keep meaning what it meant when the form changes. FieldScroll ties every record to the form version it was captured with.
- They want the office-to-field loop closed — a way to send a record back for a second visit. That is dispatch.
- They want an API-first platform their own systems, and increasingly their AI tools, can work with. That is the REST API and the MCP server.
If none of those are your reasons, it is fair to stay where you are.
What maps cleanly
| In your current setup | On FieldScroll | Notes |
|---|---|---|
| A form with elements, sections, and option lists | A form with field types, sections, pages, and choice lists | Choice labels are the stored value on FieldScroll; plan renames carefully |
| Conditional display and calculated elements | Visibility rules and formulas | Expressions are rewritten, not imported |
| Subforms and repeating groups | Repeating tables, or a dedicated subform screen | See form patterns |
| Reference tables used by picklists | Data sources with CSV import, bulk API, or managed sync from a database | Managed sync keeps the source system authoritative |
| Photo, signature, and location elements | Photo, signature, and location fields | Captured metadata is listed in security |
| Per-form data feeds to downstream systems | Webhooks per event, plus API pulls | Signed deliveries; optional preprocessing script |
| Generated documents | Report templates rendering PDF or HTML | Email, webhook, Box, and Google Drive destinations |
What to check before you commit
- Every integration that reads from the old platform. List them. For each, decide whether it will read FieldScroll webhooks, pull from the API, or be retired. The webhook event catalog and the API reference say what is available.
- Every calculated or conditional element. These are rewritten in the FieldScroll builder, not imported. Budget time per form; the builder's assistant can draft logic from a written description, and test mode runs it before anything is published.
- Reference data ownership. If your picklists come from a database today, a managed source can keep that database authoritative instead of copying rows.
- What you need from historical records. Read the FAQ on this page before loading history. Sometimes the right answer is to keep the old export as the archive and start fresh.
- Reports. FieldScroll renders PDF and HTML from HTML/CSS templates. If your current documents are Word or Excel templates, they are rebuilt, and Word or Excel output does not exist.
- Users and roles. Accounts are recreated; passwords do not move. FieldScroll's roles are organization-scoped, and form access is granted per user, team, or collection.
Running both during the transition
The transition that works is one workflow at a time:
- Rebuild one form on FieldScroll and publish it to a test form.
- Run it on one pilot site or one crew for a few weeks alongside the old form.
- Point its webhook at the same downstream system the old form fed, so the office sees one stream of records.
- Compare the two streams. When the FieldScroll stream is the one people trust, retire the old form.
- Repeat.
Neither platform needs to know about the other. The seam is your downstream system, which is already used to receiving records from one place.
What FieldScroll does not offer
- No automated iFormBuilder import today. It is tracked and not promised for a date.
- No Word or Excel document output.
- No OneDrive or Dropbox delivery. Box and Google Drive are built; a webhook destination hands the file to anything else.
- No approval workflow state on records.
- No self-serve signup. Every engagement starts with a discovery call, and provisioning is gated while launch partners are selected.
If one of those is the thing your program depends on, say so in the first call. It is a faster conversation than a pilot that stalls on it.