Editing Form Templates
A form template contains all the information required to define the form that can be filled out by the recipient. The template is where you set up all the form fields, plus other information.
There are three different form builders within HR Partner, all of which work in the same way. You have:
- Custom Forms which you can edit by heading to Forms > Configure > Templates
- Application Forms which you can edit by heading to Recruitment > Configure > Forms
- Review Forms which you can edit by heading to Performance > Configure > Review Forms
For the purpose of this guide, we are using the standard Custom Forms, but all advice and guidance is the same regardless of which form builder you are using.
When adding or editing a template, you will see the following screen:
A description of the fields is as below:
Basic Settings
| Name | A descriptive name of the form which identifies what it does to your employee/applicant. |
| Template Category | This is the category that the templates belong to - the grouping by categories makes it easier for your employees to find the form they need. |
| Description | This is a longer description that details what the template does. Useful for your team in case they need to be informed of specifics of when this form is to be used, or what it will capture. |
| Template Type | This designates whether the template is for an Employee or an Applicant (Note: Applicant forms are still a work in progress at time of writing and are not available yet). |
Form is Active |
This flag denotes whether this form is currently active and can be assigned to staff or filled in by them via the portal. Because you cannot delete a form template that has filled in forms created from it, deactivating the form is probably a better way of 'hiding' it from your employees. |
Allow Employee To Delete Form |
This flag denotes whether this form can be deleted by the employee on their portal during, or after they have completed filling it out. If you are not concerned about letting your employees delete forms sent to them, you can check this box, otherwise leave it unchecked so that only Admin users can delete forms that have been assigned out. |
Advanced Settings
Note: The advanced settings are normally 'collapsed' to save screen real estate, and you can click on the small down arrow to expand this area.
| Employee can select... | This flag specifies whether the employee can select and ad-hoc fill in this form on their employee portal without it being formally assigned to them by an admin. Useful for asset request forms or other forms that the employee themselves can instigate. |
| Hide the identity... | This flag specifies whether the form can be submitted anonymously. This means that the admin receiving this form (or any other admins) will not be able to identify who submitted this form at all. Useful for sensitive forms such as complaints or feedback on the company etc. where the employee may want to avoid negative repercussions. |
| Set a follow up reminder... | This flag will let you set a follow up reminder email to go to the employee after a certain number of days. When you check this box, you will be presented with two more fields asking for the wait time, then the frequency of the reminders to be sent to the employee if they do not complete the form. |
| Send submitted forms to... | The is the admin user who by default will receive the forms when it is sent in. This admin user will get an email notification when the form is submitted by the employee/applicant if the next checkbox below is ticked. Please note that other admins with access to the forms module will also be able to view the form sent in by the employee (as long as the employee is within their department access level). |
| Notify the person... | This flag specifies whether the admin user named above will receive an email notification when the form is submitted. |
Form Layout
The final section on the page is the actual form layout editor. To use this editor, you can click and drag different field types from the box on the right hand side, to the working area on the left hand side. You can drag and drop as many fields as you like, and you can even rearrange the order of fields on the page by dragging and dropping them accordingly.
This short video below shows you how to drag and drop, and configure fields in your form.
Tip: Start off your form with a nice header and some descriptive text which lets your employee know what they need to do.
Here are the different field types that you can place in the form layout:
| Text Field | This is a simply one line field to capture things like a name or a short piece of text. |
| Text Area | This is a larger text area which is useful for capturing longer, multi paragraph text blocks. |
| Paragraph | This lets you place some descriptive text on the form which the filler cannot edit, but provides some context about what the field above or below do. Useful for providing guidance to the filler. |
| Number | This is a numeric field useful for capturing things like dollar values or counts of something. |
| Header | This places a heading on the form, which are useful for titles or section headers. The form filler will not be able to edit these. |
| Select | This is a drop down selection field which lets the filler choose one (or multiple options) from a set presented to them. |
| Checkbox Group | This lets you specify a series of different options to the filler, and lets them choose one or more options from the list. |
| Radio Group | This is similar to the checkbox group above, but only lets the filler select ONE option from the list presented to them. |
| File Upload | This lets the filler upload one or more files. Uploaded files are stored with this form until removed. |
| Date Field | This is a date entry field which present the filler with a widget for selecting the date from. |
| Star Rating | This is a field which presents series of 'stars' to the filler and lets them choose how many stars they want to select. Useful for things like rating a specific event, person or criteria. |
Every field that you place on the page has a different set of properties that you can configure. These properties will vary depending on the field type, but there are some common ones that you need to be aware of. To edit the properties, simply click the 'pencil' icon which appears when you hover over any field you have placed:
Important Tips
When editing the field properties, there are a couple of things that you need to be aware of.
You must ensure that the Field Name (1 below) is unique within all the fields in the form, and you must be careful to NOT change this field name later once employees have started submitting forms based on this template, because this will break the links between their answers, and these questions. You must also ensure that if you have a multiple choice field (as in 2 below), that the second column also contains some internal identifier that HR Partner can use to ascertain what data to store against this question.
The left hand column will be the text shown to the person filling in the form, but the right hand column contains the actual data values that will be stored in the form. Don't leave this column blank, as that will cause data in this form not to be saved properly.
IMPORTANT: when populating both the right and column of data and the field name, please avoid use of special characters (including punctuation) as these can corrupt your form
The Importance Of Field Names
We mentioned above that it is important to set your field Name when you create your form, and not change it later. You may be wondering why, so we will explain here to try and illustrate why changing or deleting a field name can cause issues with your custom forms.
It is really tempting to change the field name, especially as the system will usually allocate a default name like ' text-5348761' to your field when you create it. This of course doesn't make a lot of sense when you export your data later, or use the API to view your employee's answers, and this is when a lot of people go back in to edit the field names to be more meaningful when they look at it as a column header in their spreadsheet later.
Why do we need a field name at all, you may ask? Well, like any database system, the answers that your employees provide has to be stored against some sort of placeholder 'key'. The actual field question text is usually too long, and can change often, so we can't store the data against "What is your favorite color of the rainbow?" because it is too long, has punctuation and spaces and other random characters in it that database systems usually struggle with.
So we need a unique placeholder 'key' that we can use to store the data against, and this is there the field Name comes in. As you can see in all examples, the field Name is usually all lower case, and contains dashes or underscores instead of spaces, and there are no punctuation marks! In fact, if you try and put spaces or punctuation in the field Name, the system will strip them out!
Consider the following scenario:- You have created a form with 4 field to capture some information from your employees, mainly their favorite color, fruit & pizza topping, and you also asked them to pick a number between 1 and 10. You call these 4 fields favorite-color, favorite-fruit, pizza-topping and pick-a-number, which is all fine.
What happens now is that when your employees John, Sally and Mary go in and fill in this form from your template, all their answers will be stored against this 'key'. So our database will create a placeholder to store their data, and it will identify this placeholder using the field Name from the custom form template. Anything the employee types in will simply be put in this placeholder, and when you later go to export the form data or view the form, our system will grab all the answers from the employees, and match them up by comparing the placeholder keys in their answer file to the field Name in the form template, and give them to you.
Now let's say you decide to change the second question. Instead of asking for their favorite fruit, you might want to ask what drink they usually order at the bar. So you go ahead and edit the field favorite-fruit and change the question text, and change the field Name to main-drink instead.
But see what has happened here? The existing answers that have already been submitted by John, Sally and Mary still have a placeholder called favorite-fruit, which still contains the information they entered earlier. But if you go to view their forms now, you won't see that, because when our system looks at the form template, there is no such field called favorite-fruit any more, so it can't match these values to the form any longer.
Even worse, if you edit the old forms to change any of the values that you CAN see, then when you save it, the unmatched placeholder fields will be deleted in the database as they will be considered invalid data. 😧
To make things even trickier, let's say that Harold comes along and creates a form based on the template you changed, and saves his data, then his form will be correct and contain the new placeholder. But the forms from the other 3 employees will still have invalid placeholders.
Now you are stuck, because if you rename the field Name in the template back in order to see the data from the other 3 employees, then you will break the form for Harold and his answer to his main drink will be lost!
So you see why it is important to get the field names right from the outset, and make as few changes as possible to them during the life of a custom form - especially once employees start filling them in. In our recommendation, it is always better to retire old forms by deactivating them, then make a copy of the form with the changes you need and deploy that to your team.