We appreciate there is a lot to get to grips with in InfoCapture and its particular mechanisms will become familiar with the experience.
An established form is one that has been in use for a period of time and has ticket submissions already made in it.
This article will provide more detail on how to approach making changes to established forms already in use, and those dealing with potentially thousands of tickets in them.
It pairs closely with our best practice guide for form functionality changes, it is recommended to read these guides in tandem.
Your administrative team can request training on InfoCapture and/or undertake our eLearning Course, watch our four-part webinar on form building as well as check out all our written guides to gain an understanding of the application.
Take a look at our other best practice guides for more information on how to manage InfoCapture effectively:
Workplaces are dynamic and it's expected that your responsible users will need to make updates or changes over time to your forms, which will become larger and more important as time goes on.
It's therefore paramount that responsible users understand how to make changes to established forms safely to maintain their integrity and prevent causing issues that can render the form unusable until investigated.
If you want to make a change to an established form, consider the points explained below first.
I want to add a new field to a form
This action is always ok to make to an established form as it is an addition that will not affect anything currently in place when created.
Add in your new field and make sure to leave a version comment so it's evident over time and to other administrators what was updated.
- Do form field changes need to be applied to all tickets?
Next, consider your expectation for this new field - do you wish it to be seen and used for new tickets going forward only, or would you actually like it to appear in all past tickets too?
Only for new tickets: Only new submissions will employ the changes made to the form. Past tickets remain untouched.
Replace the previous version with this one: Existing tickets, belonging to the previous version of the form, will now belong to the newest version of the form and changes made to the form fields will be reflected on those tickets.
Replace all previous versions with this one: All existing tickets (regardless of which previous version of the form they currently belong to) will now belong to the new version of the form. Any changes made to the form fields will be reflected in all existing tickets.
Great care should be taken if either of the latter two options (i.e. replacing existing issues with the new version of the form) are selected.
- If yes...
Select either option to apply to all tickets and save.
This means your new field will have now been applied to past tickets and will be evident when looking at them or editing them. (If field visibility rules have been applied on the field, it will follow these).
The field will appear in past tickets but depending on its type, it will be blank.
If you wish for the field to be filled out each ticket will need to be edited and the field updated before saving again.
Past tickets with the new field applied may not appear in searches or reports until they have had this field filled out.
Tickets can be edited and updated manually individually as needed, however, tickets can be updated en masse to rectify the situation more quickly using the 'Update' function:
So for any change applied to past tickets, an administrator will need to manually update them to ensure all fields appear filled out as you require.
- If no...
Select the 'Only for new ticket' option and save.
The new field will appear for new submissions going forward for users to fill out.
Past tickets (or those submitted in all other previous versions) will not have this field evident.
In searches and reports for the new field, only tickets that have it will be returned i.e. not past tickets where the field was not applied.
- Required fields
If you have set a new field to be required and applied this to all tickets, depending on its field type all tickets will need to be manually updated to rectify this.
The point of required fields is to prevent the user from leaving that field empty when submitting.
Adding a new required field and applying this to past tickets circumvents this functionality.
It means if a user edits a past ticket they will not be able to progress until it is filled out.
This is something to be aware of when making fields required and applying to past tickets, an administrator will need to update all past tickets efficiently to avoid end users becoming confused they cannot proceed if editing tickets as part of their tasks.
I want to make a change to an existing form field
This is the trickiest scenario to manage as it’s not recommended to make certain changes to pre-established fields.
As the database references ticket information making changes to this directly can make it no longer recognisable in searches, reports etc. and render forms unusable by end users.
If you have made a major data change to a field it can easily be reverted by deleting the most recent form version.
Certain changes to existing form fields are ok to make and check in to all or just new tickets:
- Adding in new values to a select field
- Changing field properties, only:
- Updating what is set in the field as the 'default value'
- Adding in an optional hint
- Changing the order it appears in the form
- Changing how its label appears (or other CSS)
- Making the field required or disabled
I want to make a change to form logic
Form logic is not tied to the form version, so any change to these elements will automatically apply to all tickets.
Depending on the complexity of your form one small change could have a knock-on effect on other elements and break them. This could mean the form won’t function as it did before or in the way you expect.
This is detailed further in our best practice guide for form functionality changes.
Any change made to field condition sets needs to be prepared for and traced through your form to confirm what else this will affect when changed and if this works for you based on the purpose of the form.
Check triggers, field visibility sets, SLAs, automatic changes, workflow and notifications ahead of any changes so these can be discussed internally and in line with your forms aims.
Any change to one of these areas alone instead also needs to have the implications of this considered before being applied.
Some areas are low risk (Notifications) compared to others (Field visibility sets) due to the functionality they are involved in and how this deals with data presentation to end users.
This is another reason to keep forms as simple as possible, as changes to form logic won't be too complex to understand the effects of or too difficult to find out.
Testing form field changes
If a form is being built or is in the testing phase where test content submitted in it will be removed before the form is made ‘live’ for end users, form logic or field form changes can be made more freely as there will be no past ticket data to consider.
It is still best to follow our best practices to ensure the completed form and its logic are prepared ahead of the form going live.
If you are unsure what impact the change you wish to make to your form will have, submit a support ticket where we can review this with you before any changes are applied that could negatively impact your form and users' experience.
Reminder: You can export a project and import this once more on your site, renaming it to indicate it's for testing purposes. You can then apply the changes you want to this form to see if there is any impact and how best to rectify this before applying it to your live form.
