In this article, we define a pre-filled web form as a web page with certain editable fields that visitors can fill. Pre-filled forms can remain nameless — unassociated with anyone in particular. But in many cases, they require a name or other means of identification. A classic example of this type of form would be the contact us pages you see on many websites, which need to know your email address at the very least.
The thing that distinguishes pre-filled forms that are personalized from prefilled forms that are not is that the former can remember your name but the latter always have to ask.
The name and email you provide when registering with a website identify you as a registered user. At a later stage, when the website needs to know more about you — like your physical address to ship a purchased item to — it generates a form with your name already filled so you don’t need to fill it in again.
Another example would be collecting feedback: an activity that benefits from being automated to the highest degree — the less info requested the better. Below, we’ve modeled this use-case using personalized pre-filled forms that you can filled and send in less than ten seconds.
The main advantage of personalized forms is the data you submit can never be lost through human error and will always be associated with a particular person’s record on a back end. This is efficient automation, as opposed to the inefficiency of non-personalized forms, where you have to enter your name every time, even if you’re already registered. Personalized forms can also be customized based on the user data entered during registration.
Here’s the complete list of use cases for personalized pre-filled forms:
-
User profile updates with more information
-
Feedback for purchased goods and services
-
Invoice distribution (with a personalized link for payment)
-
Online tests (for education, certifications, etc.)
-
Any kind of information that needs to be submitted electronically and associated with the person who submits it
Existing solutions (useful but with limitations)
The two most popular — Google Forms and Microsoft Forms — are both non-personalized. Google Forms ask for your Google user ID (at Gmail or G-Suite). This avoids certain errors due to sloppy typing like misspelling a name or e-mail. Users are limited by having to have a Google ID and be willing to provide it. Microsoft Forms does not yet require any user-specific ID, trusting solely to the user’s manual input.
Adobe has its own forms product — pdf forms. PDFs are relatively easy to use and have multiple features, but again, to fill forms, you have to be registered with Adobe. And, unlike Google and Microsoft forms, the Adobe option is not free: you might like to check out the cost element here.
There’s always the custom-coding option with its obvious pros and cons.
No-Code options
We are presently designing a convenient fully automated way to engage with your user base via personalized pre-filled forms that require no coding and don’t rely on third-party online accounts.
The solutions described below used our Processica Apps back-end. For the front end (where a particular form can be built), we explored the following:
-
UI: Web-Forms (JotForms, CognitoForms)
-
UI: Microsoft Power Platform (Power Apps Portal and DataVerse)
-
UI: Web/Mobile apps (Bubble) Pros/Cons
1. Web-Site Builders
Couldn’t find a ready-to-go solution with Web-site Builders (we investigated WebFlow and Carrd). Web-site Builders architecture geared up towards constructing a web page from the data available on its own back-end, while constructing personalized landing pages requires a back-and-forth communication with a third- party back-end.
2. Web-forms
The only available method we found for Web Forms (we tried several see below) is to embed the personal information into the URL that will be used to generate the pre-filled form. Since there is no commonly used way to encrypt the URL, personal user information may be vulnerable.
This method works fine in the intranet environment, but if used in the public domain, it needs to be handled with care as it is not 100% secure.
JotForm recently removed the embed code function from their custom plugins. Without this function, we couldn’t find a way to deliver data from the back end to the form, even via the URL. Some plugins seemed to have these functions (the Get Referrer plugin for example), so maybe there is a way to do it, but not with the generally available functions.
CognitoForms supports extracting personalized information from the URL., it also has a function that allows you to “resume” work on the form. The idea is that when you fill the form out once, it can be saved using your e-mail address as a reference. The user can access the saved form at a later stage by providing the e-mail. This functionality is rather similar to Google Forms and Adobe in the way that you cannot send your user a personalized link.
We described JotForms and CognitoForms, but tried several more (Dorik, FormKeep, Typeform, Paperform). If you interested in specifics – feel free to reach out, we would be glad to share it.
3. Microsoft Power Platform
Has a very broad set of buildable forms with tons of functions and is integrated with CRM Dynamics, which broadens the set of functions and use cases that can be achieved with DataVerse. This solution may not be mainstream for no-code makers though. If you are interested in this option, please reach out and we’ll investigate it further.
4. Web/Mobile apps builders
The following schema was tested and worked on Bubble without coding. You need to configure Bubble’s plugin to communicate with a back end containing your contact data (in this case, we used Processica Apps back end).
URL to instantiate a personalized pre-filled form will include only a reference (hash) to a person’s record.
When received, Bubble communicates securely with the back end, pulls the necessary personal information and displays it on the form. Bubble supports OAuth, key-based authentication and traffic encryption. So this way is secure.
When the form is filled and submitted, data is sent to the backend web-hook or API call on the back-end side.
We demonstrate how it is done based on Processica Apps’ back end, but this method is not limited to it. As far as the back end supports mentioned above functions.
Conclusion
Thank you very much for reading this material. We believe that personalized pre-filled forms are a critical element for efficient communication with your audience or user base. It provides both automated efficiency (so users can enter less information), prevents data loss due to human error and offers a more secure means of communication.
If you are interested in any of the proposed approaches (even those that failed to find a solution), feel free to reach out. We would also love to receive your examples of your use cases involving pre-filled forms or similar functionality – even if some of them are only hypothetical.
Your feedback on the matter would be greatly appreciated. It will help us to define our roadmap and prioritize certain product functions that are in a need by the no-code community.
You can always reach out directly to me or to Processica Apps team.
