FlexiForms Process Flow
This page will explain the steps of using FlexiForms, from Designing forms to Running Jobs after form completion by the end user.
Last updated
This page will explain the steps of using FlexiForms, from Designing forms to Running Jobs after form completion by the end user.
Last updated
Please have a look at the diagram below before diving into details:
The process flow of FlexiForms is as follows:
Once the form owner [design] and sets up the form, the form is ready to be filled by the user. At this point, the question of how to delivery the form to the end user is important. Before diving into Delivery Methods, we should talk about Form Links.
By default, the forms are accessible by any user who has the link. We can call this delivery method "public delivery". The default link of a public form is as follows: <flexiforms domain url>/<form id>. Also, the same user can fill in the form several times using the same link if there is no [verification] to prevent this.
The second delivery method can be called "private delivery". A form link can be made private (for a user or some users) in different ways, using at least 1 verification. For this purpose, we can use a query parameter with different values for different users / user groups, and check this value in the verification stage.
The third delivery method is a special kind of private delivery, and can be called "unique user link delivery". The method allows generating a user link for each user. Furthermore, if controlled unique user links are opted, the system automatically checks whether the user link is already used (whether the user already filled in the form). Also we can assign an expiration time for each link so that the user will be restricted to a certain period for her to fill in the form.
Once the form is delivered to the user, if you want to check if the user belongs to the target audience, you can utilize Verifications.
Verification is the process that checks whether the user belongs to the target audience of the form. FlexiForms has a very flexible verification mechanism. It basically checks the source values
the user inputs (passwords, emails etc.)
request data (a query parameter for example)
against the target values which might be
a fixed text
a request data value (a query parameter, or any special information such as JWT tokens or authorization-related information)
a web API
You can specify multiple verifications for a form, meaning you can define multiple source-target pairs.
Source values are checked against the target values using different transformation (such as encrypt or convert to lowercase etc.) and comparison operators such as "equals", "greater" or "contains".
Let's say you want the user to enter a fixed text (a password) that you provided when the user clicks the form link. You can embed an encrypted text in the form link, and design the verification screen where the user will be asked the password. This way, FlexiForms check whether the password equals the decrpyted text in the form link. Note please that the source is user input and the target is a request data value.
In a similar but simpler scenario, the user enters a password which can be checked against a fixed value, where the source would be user input and the target is fixed text.
In another scenario, the user enters her email and FlexiForms can send this information to a Web API. Web API returns whether the user belongs to the target audience or not. It checks, for example, the email belongs to a person who has applied to a job, who wants to fill in some forms as part of the job application process. Note that the source is user input and the target is Web Api in this scenario.
FlexiForms allow you to design User Verification form, just as the Main form (the form the user will fill in).
Feeding a form means loading the form with some data. This data is usually previously filled form data. FlexiForms supports 4 ways of feeding (feed types).
Query Parameters on Form Link: This is the simplest feeding. A field on the form is pre-populated with a parameter on the form URL. For example, the city information (Auckland) https://flexiformsqa.azurewebsites.net/ba19aee1-5744-47a4-1c10-08dd6a5525f4?city=auckland is set to the City field (question) on the form.
Master form data: This type of feeding is used to transfer form data from the source form to the current, target form. Let's consider the following scenario:
In this scenario, Review Form is fed by Attendance Request Form, and feed the Final Decision Form.
Attendance Request Form
-
Review Form
Review Form
Attendance Request Form
Final Decision Form
Final Decision Form
Review Form
-
Posting Values: This feed type is used to post form data from an application to FlexiForms. A typical scenario is when we want to modify or delete some data on the database by using FlexiForms.
Web API: This feed type is used to pre-populate the form based with some the data provided by an Web API. We can send some request data (a query parameter for example) to the Web API, and Web API returns some data to the form, which pre-populates some fields.
https://flexiformsqa.azurewebsites.net/fa3da4fa-1fbb-4cb2-1ce6-08dd209b2788?feed_key=aSecretToSend&form_data_id=7082FA22-6745-469A-8158-1F0339344EA2
For example, this feed setup and the form link above together tells FlexiForms that "pass "7082FA22-6745-469A-8158-1F0339344EA2" to https://flexiformssamplewebapp.azurewebsites.net/api/feed?form_data_id={form_data_id} as form data id, and feed the form with the returned form data.
If the delivery method is User Unique Links, since the link is unique for each end user, the end user can save the form entry temporarily as a draft. Then whenever the user uses the same link, the draft is loaded automatically.
If you have not specified any verification step, or if the user is verified, the end user now can start fill in the form. Depending on the form design,
the user can be branched to different sections (pages or panels) of the form based on her answers
some questions can be visible or hidden again based on the answers
If the form delivery method is "user unique links", the end user can save the her form entry in the form of draft and continue later when she loads the form later. When the form is completed, the draft is deleted.
the end user completes the form by clicking Complete button. The title of this button can be changed in the design model.
the completion of form is followed by a thank you page. You can customize this page in the design module.
Once the form is completed, FlexiForms starts running the jobs. If there is an export job, it is run first. If the export job (or one of the export jobs) fails, the system does not attempt to run other jobs. Instead, it marks the form entry as failed so that the Recovery Process re-runs the jobs.
Export job(s) is / are followed by other jobs such as Import Into DB jobs, or Transfer jobs. If one of the jobs from the same (non-export) job type (e.g. the second transfer job of three transfer jobs) fails, the system proceeds to the next job, but marks the failed job so that the Recovery Process re-runs the failed job.
Whatever happens to the form entry is stored on the database (Master Data Form Table). If, for example, a job failed, we can see this from Master Form Data grid on the Form Data & Files page on FlexiForms Admin page.
We can specify rules for any job, such as city="Auckland", or age>18, where city and age are names of some questions. FlexiForms will check first if the rule is satisfied. If satisfied, it will run the job and proceeds to the next job in the workflow. This is not considered as a failed job. It is expected and no failure mark is used for these jobs, even for export jobs.
Regardless of the delivery method, form identifier (form id) is used in the form link (every form has unique id such as "f421ddcd-6231-46ad-9112-a4a5b1144bdc") in the following format: <flexiforms domain url>/<form id>. For example, the link of a publicly accessible form is .
In some cases, some query parameters can follow this, for example: ?city=auckland. The form can utilize this extra information in many different ways such as for feeding the form, or for verification. Please see [Request Data] section to see how to make this information available for FlexiForms.
the form may prevent the user to proceed because of validation rules. Some validation rules are easily specified via built-in simple rules such as Required, Format validation, Minimum Value or Maximum value validation. The form designer can also specify more complex or dynamic validation rules using some JavaScript code. FlexiForms allows you to define these rules in a central place. (See for details and examples about custom validation rules)
