To add a ‘Special’ field to your form, click the ‘Special’ icon.
Buttons
These are used to run integrations when pressed by the form filler and multiple integrations can be attached to a single button. Any integration can be attached to a button with the most common being printable integrations used to generate PDFs on the spot or database lookups to populate certain fields in the form.
While any integration can be added to a button, some integrations, such as escalation integrations, would make more sense being attached to a process stage (eg. as a submission integration) or another type of field (eg. a select field).
Button settings include:
- Label name: the display name that form fillers will see
- Data Name: used to identify the field when processing data
- Help text: appears as blue text guidance for the form filler when the field is clicked on, a blue question mark will appear next to fields that have help text attached
- Lookup: search for and select the desired integration you wish to attach to the button, you can add multiple integrations which will all run when the button is pressed
- No Results message: will be displayed when a look up fails to return any results
- Action: Custom javascript can be added here to run on the button - note the platform assumes the code added to the action on the button is JavaScript and so the <script> and </script> tags usually used to encapsulate javascript are not required. (Firmstep cannot provide support for custom javascript)
Upload
Upload allows the user to upload a file if necessary. (the type of files permitted and max size can be controlled)
Read Only - refers to after a file has been submitted, for example, Stage 1 customer uploads field. Stage 2 is read only so it can't be deleted.
Summary Field - displays summary on Achieve Service/Dash Dashboard.
Subform
More details on subforms and their use.
Rich Text
Unlike the HTML or Static Text fields (outlined further in our Content Fields documentation), or a Text Area field, this creates a field using a WYSIWYG text editor, thereby allowing the user input more complex content. Since these fields require an understanding of the use of an editor, we advise that Rich Text fields are used internally only.
Even internally, there are some known behaviours of the Rich Text field which mean an HTML or Static Text field is likely a better fit for the user. Please see the Known Behaviour section at the bottom of this document for more information. In particular, we recommend CSAs build the formatting elsewhere (e.g. in Wordpad or an online HTML converter tool) to ensure formatting pulls through correctly.
If improving the usability of the rich text fields becomes a key focus area for the product we will take this into consideration. As our focus is on platform performance improvements like Integrations V2, we are not actively investigating a replacement for the rich text field editors at this time.
Please also note that the Rich Mode Calculation, shown below in the field options, is deprecated.
The Rich Text field will look as follows:
Rich Text fields are put on forms to allow the filler to enter Rich Text (If you take the display condition off and fill the form in you will see this). If you want to add Rich Text to a field yourself as the form builder, then you need to use the Static Text field.
Auto Lookup
Adds the ability to query and check data in other systems outside of forms whilst the forms are being completed. Both webservices and databases can be queried as a lookup; the lookup query can pass values in the form as part of the query. Examples of commonly used lookups include:
- Postcode lookups to populate address fields.
- Populating customer details into forms, where that data lives outside of the Firmstep Platform.
- Checking availability for booking forms.
Lookups usually run automatically when the form filler navigates to the section of the form that the lookup is on.
- Lookups that run on a button will not rerun when returning from a cancelled payment or a save.
- The minimum/maximum length validation options in the validation conditions will not work on rich text areas by default. The fix is replace min_value or max_value in the validation message with the number of characters you are setting as a limit. Please input at least min_value characters >> Please input at least 100 characters. This will allow the minimum/maximum length validation options to work.
- Where rich text fields are used to build an email response etc, there are issues especially where special characters such as apostrophes and ampersands are used - we advise CSAs to use Wordpad to type the content where more than a few words are required and copying from Wordpad to the rich text field.
- Tokens also break the rich text field in unexpected ways; this is an issue which is being considered for development.
- HTML is escaped when passing values from a rich text field to a static field. In order for the token in the static text field to recognise the HTML entered into the text area field, you have to add a # symbol to the beginning of the token.
- When the rich text field has a value which contains form tokens, and the user navigates throughout the form, the text will revert to the default value when the user returns to the relevant section.
- Intermittently, the cursor may jump to the start of the rich text field as it is being filled (whether building / submitting a form or using within integrations), therefore interfering with the user’s attempts to enter text.
- This is an issue with the provider of the rich text fields, which is an external library we employ. At the moment we are not planning to use a different library to resolve this, due to constraints within the product. This may be something we consider in the future but it is not currently in the scope of our roadmap.
- Rich text fields are not designed to display read-only texts. Please use static text or HTML text fields for this.
- We do not recommend having hidden rich text fields in a form as there may be issues with the fields pulling through tokens.
- Font colour changes are not permitted in rich text fields. This is because the use of colour can cause accessibility issues. Furthermore, not all email clients handle colours in the same way, causing an inconsistent user experience.
- Sometimes caching issues can be encountered by the TinyMCE editor (which powers rich text fields). If clicking to open a text field will not load the editor for that field, please try clearing your cache.
- Rich text fields can sometimes add extra HTML, for example extra <div> tags.
- To create a line break in a rich text field you need to press ‘Shift’ and ‘Enter’. Pressing ‘Enter’ alone will move to the next row but this spacing will not render during fill in.
- This is a fault within the TinyMCE editor which we use for the rich text field functionality, and is unfortunately not something we can change.
