How it works

Before you begin building your first Serverless Data Managament application on <>, it is beneficial to understand the underlying concepts of how <> 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 be the best way to position yourself to utilize this powerful platform to its fullest potential. Let’s start with one of the most important items, Forms and Resources.

Forms and Resources

At the heart of the 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.

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 Serverless 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

First Nametextfield
Last Nametextfield

Form 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 your companies next Human Resources Portal where the HR director should be able to onboard new Employees, manage the Employees HR related forms and submissions, as well as manage Events within the Company.

The Resources

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


  • Admin - The HR administrator
  • Employee - The Employee records
  • Event - The events objects.

The Forms

In this example, we also talked about “unstructured” data forms such as the HR Forms in which the Employee 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 Human Resources person. These are your Forms


  • W4 - Tax form each employee needs to fill out.
  • Employee Onboarding - The form every new Employee fills out for onboarding purposes.
  • Event Registration - The registration form which Employees fill out to register for an Event resource. allows you to build a Data Management 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 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 Data Management applications.

Form Building

One major capability of is that it leverages an easy to drag-and-drop form builder to dynamically create the Forms and Resources for your application.

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": "Last Name",
      "key": "lastName"
      "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"

Here is a Codepen demonstration of this JSON schema building that should help provide some working examples of how this functions.

See the Pen Form Building and Rendering by Travis Tidwell (@travist) on CodePen.

By creating this schema, this form is now capable of being dynamically rendered within the Serverless 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 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 a User Registration form, where we would like to Save their record, Send an email to an administrator of their registration, and then finally Log that user in (generate an auth token) 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

Find out more about actions in the Actions Section of the User’s Guide.

Roles and Permissions

Every project within 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, 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, the most important of these are as follows.