How Nintex Forms work
This topic describes how Nintex Forms work.
There are several ways of looking at how a form works:
- You can look at the perspective of the form from the point-of-view of the user entering data into the form.
- Or, you can look at how the form maker uses the Nintex Forms designer to create the form and user experience.
The Form User Enters Data into the Form
SharePoint users can interact with a Nintex form to enter data into a SharePoint list or Nintex workflow. The form user opens the form on their device. The form displays the appropriate layout for the device that contains a set of controls such as text boxes, radio buttons, and lists. The layout is sized for their device, such as a desktop Web browser, a tablet, or a smart phone. The controls are positioned in relation to the margins of each of the defined layouts.
The form users tabs through each of the controls and enters information within the interaction limits of each control. For instance, a text box only allows the user to type text. A radio button or check box only allows the user to select or deselect the control. Some controls grab data from other sources such as SharePoint lists, variables from the workflow, external SQL databases, or external RESTful web services, and then allow the user to interact with this data. For instance, a web service control may call an endpoint that delivers store names, and the form user would select from these store names.
Once the user has entered data, the form can evaluate the entered data. It can perform validation defined in validation rules. The form can also use the data in other controls to perform calculations or lookups with external data sources. The form can also use the entered data to reformat portions of the form, to display controls or control sets that were hidden, to change the formatting of the entered information, and so on.
Finally, the user can click a button to submit the form. When the form is submitted, the data associated with each of the controls (both hidden and visible) is sent to the targets of each of the controls. Typically the controls will be bound to persistent storage such as the SharePoint list. Controls can also send their data as variables to a Nintex Workflow, send data to a SQL database, or post data to an external Web Service.
The Form Maker Creates the Form
When you want to create a form, you will create the form using the Nintex Forms designer from the context where you expect the user to interact with the form. In SharePoint this means you may create the form in the SharePoint list or you may create a start or task form in a Nintex workflow. Forms created in a list will automatically create controls associated (that is bound) to the SharePoint list columns.
For example a list containing contact SharePoint list columns such as a first name, last name, street address, city, zip code, phone number, and email will automatically create a form with the appropriate controls for each of those columns. That is the last name may be bound to a single line text field. A column associated to a list will result in a list control. Thus your Nintex list form will be found in the context of the SharePoint list. A task or start form will be found within the context of the SharePoint workflow with access to workflow variables and the associated SharePoint list. In both cases, some of the controls such as SharePoint controls and the people picker will have access to data within the SharePoint environment.
For each control on the form you can set inline functions using the expression builder, CSS styling options, rules, and state properties such as visibility or read/write access (locked or on-locked). Each control can also be bound to a data source. This means when the form is opened it is associated with the particular record and the record values from the data source will load. Or if the form is creating a new record, then it will write to the column IDs or other targets when the form user clicks save or submit.
You can add controls that will provide functionality not found within the set of SharePoint column types. You can then bind and create new columns in the list, or you might store the control data into a variable that will in turn be used by a Nintex workflow.
As the designer you will balance the process of collecting quality data from your form users, but also making the form easy and clear to use, and storing the data in a way that will be meaningful to your enterprise.
Nintex Forms provides a number of out-of-the box mechanisms to do this, and a number of methods of making modifications to the form.
Out of the box tools
- Form Controls
Nintex Forms comes with 21 controls from standard controls such as lists, radio buttons, and text fields, to composite controls such as geolocation and Web Service connectors.
- Control Data Binding
Nintex Form controls are inherit form the ASP.NET control class and bind with server side validation and the standard set of events. They are built to bind with SharePoint lists, but can also support sending and receiving data to SQL and Web Service connections. In addition start forms and list forms can access variables set in the workflow context.
- Inline Functions
You can set Nintex form controls to run inline functions such as calculations.
- Validation Rules
You can set at the scope of the form rules that are associated with individual controls to perform validation rules. For instance, you can check if a check box is checked, or if a particular value has been selected in a list. Rules can be used to trigger JavaScript or change the state of controls, such as visibility or enabled. These are client-side rules.
- Formatting Rules
- You can set the scope at the scope of the form rules that are associated with individual controls that change the format of the controls. For instance, you could have a role that changes key text boxes to red if you a particular value has been entered in a list. These are client-side rules.
Points of modifications
- Custom Controls
You can create a managed code solution for a control based on the NintexFormControl class and deploy the control as a SharePoint solution file (.wsp). Custom Controls can be used to add new user interactions in collecting data. For more information see Create a custom form control sample.
- Custom Inline Functions
You can create a managed code solution deploy a SharePoint solution file (.wsp) containing your own functions, and then use PowerShell to register, set, and configure the functions so that they are accessible through the expression builder in the Forms designer.
- Data Binding
You can expand the data binding to bind your data to SQL or a Restful endpoint. This will allow you to use Nintex Forms to directly read and write to persistent data stores.
- Custom CSS
You can restyle the form or control using your own style sheet to support your site branding or the particular requirements of your solution.
- Custom JavaScript
JavaScript can be added directly in the Forms designer and associated with a control or form. You can also add scripts to a control in your managed solution, and it will be deployed along with your SharePoint solution file.
You can use JavaScript to create:
- Custom form interaction
- Custom validation rules
- Custom formatting rules