Overview of Form.io

Welcome to Form.io!

Before you begin building your first Progressive Web application on Form.io, it is beneficial to understand the underlying concepts of how Form.io works. While this platform provides a very simple and easy to use form builder interface, there are many unique developer features to it that enable it to address customized business process applications, and complex data management applications. Because of this, it can be integrated into a wide variety of enterprise-class platform applications spanning across many different industry sectors. Spending the time to gain a deeper understanding of how to utilize the many features and capabilities of the platform is the best way to position yourself to utilize this powerful platform to its fullest potential.

How it began

The Form.io platform was originally created in 2015, just as the web was emerging from a massive paradigm shift of web development where JavaScript was being redefined as a full-stack application framework. Before this time, web based applications were all constructed in the same way; as Server Rendered Applications. These applications leveraged monolithic technology stacks such as .NET, LAMP, Ruby on Rails, and Java, and all worked by utilizing the server to perform dynamic HTML renderings that were then sent to the client on each page request. These Server Rendered Applications were necessary since the web browser, for a long time, was not capable of executing complex dynamically rendered applications on the clients computer. This all changed, however, with the introduction of Smart Phones (starting with iPhone) where web based applications could now be rendered in the palm of your hand. Through this, web technologies quickly evolved to enable browser technologies to be capable of executing JavaScript in a very performant way. This brought about the next generation of the web, the Progressive Web.

While this next generation of the web has been positive for a number of reasons, it did however, create a gap in the web development industry where building data driven form based applications became a significant challenge. Form.io was created to fill this gap, by creating a platform that bridges the client based applications with backend services, through a common connective tissue found in every data driven application. Forms.

How it works

The power of Form.io starts with the Form building process. When you use the Form.io form builder, instead of generating an HTML webform, you are instead creating a JSON schema. This JSON schema is then used to both render the forms within the client applications (using our Open Source JavaScript renderer) as well as used to generate the REST API interfaces on the server.

Now that we have an idea of how Form.io works, let's learn about the most important fundamental concepts of the Form.io platform, Forms and Resources.

Forms and Resources

At the heart of the Form.io platform, is the ability for web application developers to create the Resources and Forms for their application using our simple drag-and-drop form builder.

Using the form builder to create a new Resource called "Employee"

While Resources and Forms share the same structure and form building process, they are distinctive from one another in how they are utilized. It is important to understand what they are, how they are used, and also what makes them different so that you can construct your project with a structure that can support your Progressive application requirements. Resources and Forms are defined as follows.

Resource Definition

Resources are the "structured" data objects that support your application. Anything that has a static data structure can be defined as a Resource. For example, Users within your application have a data "structure" as follows, and therefore are considered Resources within Form.io.

Forms Definition

Forms represent the "unstructured" data that is used to supplement a Resource. For example, a Customer Survey may have free-form questions (fields) like "Did you enjoy your visit?", and those free-form fields should be associated to the Customer who submitted it. In this example, a Customer Survey would be a Form that references the Customer Resource.

To help explain these concepts, let us provide a real world example.

Example Application

Let’s suppose you are a developer responsible for building a multi-tenant Clinic patient onboarding application. In this application, each patient must fill out a form and will then be assigned a Physician. The Physician will only be given permissions to see the Patient information for the patients which he/she has been assigned.

The Resources

In this example, we can easily identify the “structured” objects that would be used to construct a working application. Each of these objects may relate to one another, but should be stored as individual database collections (or tables). These “structured” objects would be defined as the following Resources.

Name	Description
Patient	The person who needs to be seen by a Physician
Physician	The person who is going to be assigned a Patient.
Admin	The person who is responsible for collecting and managing the Patient information per Clinic.
Clinic	Since this is a multi-tenant application, we would need the ability to have several Clinics managed by the applications.
Appointment	This would be used as the entity used to assign a patient to the physician at a specific time (appointment). This would also be used to assign the "Patient Onboarding" form.

The Forms

In this example, we also talked about “unstructured” data forms such as the Patient Onboarding Forms in which the Patient would need to create submissions and then be able to manage their data. These should be “unstructured” data collection mechanisms and must be capable of being flexible and in some cases created by the Clinic administrative person. These are your Forms

Name	Description
Patient Onboarding	The Patient Onboarding form
Proof of Insurance PDF	A PDF of the proof of insurance
Patient Physical	This will be the form that the Physician uses during the appointment

Form.io allows you to build a Progressive Web Application by consciously separating these two constructs to help you organize how the Forms and Resources can be used together to create a flexible and robust Data Management platform.

Pro Tip

Technically Resources and Forms are the same thing. The simplicity and power of the Form.io platform treats them both the same from an API perspective, but they were separated to assist the developer to keep track of them as separate entities since they are used differently within the Progressive Web Application.

For a more detailed walkthrough of the forms and resources, please go to the Forms and Resources User Guide.

Form Building

One major capability of Form.io is that it leverages a simple, drag-and-drop form builder to dynamically create the Forms and Resources for your application.

Drag and Drop Form Builder

Our form builder, however, is very special where instead of building an HTML form, it instead generates a JSON schema representation of the form or resource. A very simple example of what a schema looks like is as follows.

{
  "title": "Person",
  "display": "form",
  "type": "form",
  "name": "person",
  "path": "person",
  "components": [
    {
      "type": "textfield",
      "input": true,
      "inputType": "text",
      "label": "First Name",
      "key": "firstName"
    },
    {
      "type": "textfield",
      "input": true,
      "inputType": "text",
      "label": "Last Name",
      "key": "lastName"
    },
    {
      "type": "email",
      "key": "email",
      "label": "Email",
      "inputType": "email",
      "input": true
    },
    {
      "input": true,
      "label": "Submit",
      "key": "submit",
      "action": "submit",
      "type": "button"
    }
  ]
}

By creating this schema, this form is now capable of being dynamically rendered within the Progressive Web Application (using Angular, React, etc), but is also used to automatically generate the REST API to support this form using the same JSON schema. This API can be viewed as follows.

Form.io Swagger 2.0 API Specification

Example Application

For an example application that illustrates how the Form Builder works in creating JSON schemas, please go to the following site.

https://formio.github.io/formio.js/app/builder

Form Actions

Once a form is submitted by the user, the data is sent to the API server where it is then processed through Actions. Everything from Sending Emails, Authentication, and even Saving the submissions in the database are configured through independent actions associated with the Form or Resource. Another way to think about actions, is that they serve as configurable middleware that can be attached to a Form, which perform tasks and data manipulation on the submission payload. Every Form and Resource can have an unlimited amount of Actions attached to them, and every action is sequentially executed in the order they are “stacked”.

Here is an example screenshot of the Actions associated with an Employee Application form, where we would like to Save their record, Send an email to an administrator of their registration, as well as send an email to the application, and then finally send that application information to an external CRM (such as Salesforce) for the application to then process.

Here is a list of some actions that can be executed on every Form or Resource.

• Email - Sending an email with the form information either to the person submitting the form or to a project administrator.

• Save Submission - Saves the submission payload to either this form, or forward it along to a Resource

• Login - Authenticate a user by generating a JWT token for the submission payload that was submitted.

• Webhook - Trigger a REST API call to an external system when an action is executed.

• Integrations - We offer a number of integrations that will send the form submission data to 3rd party providers.

• SQL Connection - Connect a form submission to an external SQL database including PostgreSQL, MYSQL, and MSSQL

For a more detailed walkthrough and examples into the Form Actions, please go to the Form Actions User Guide

User Authentication

The Form.io User Authentication system is very unique from other platforms. While other platforms have distinct User entities, and are managed within their own API and Database namespaces; Form.io is different in that a User is actually a Submission within a Resource form. This allows any Resource to define a structure of a User account, as well as have many different kinds of user models within your application. This becomes very useful if your data management application needs to keep track of multiple User models as well as manage the different ways in which users can be assigned access to other forms and submission data.

For a more detailed walkthrough and examples of User Authentication, please navigate to the User Authentication & Authorization guide.

Roles and Permissions

Every project within Form.io can provide custom Roles which users can be assigned when they authenticate into the platform. These roles can be used to categorize users based on what access they should have within the Data management functions of the API platform. Essentially, Form.io provides a way to create dynamic Roles, assign those Roles to Users, and then designate what Permissions each role should be allowed to do within the platform.

The Permissions a role has is configured on a per-form basis, which allow access control on who can perform certain functions on that form or submissions within that form. These permissions are based on CRUDI operations (Create, Read, Update, Delete, and Index), and are able to be associated to both Forms as well as Submissions. In addition, each permission is configured based whether a user is trying to perform those actions on their OWN records or other peoples records (ALL). In aggregate, this provides a total of 20 different permissions that can be configured on a per-form basis.

For more detailed information, please check out the Roles and Permissions User Guide.