We appreciate there is a lot to get to grips with in InfoCapture and its particular mechanisms will become familiar with experience.
Below are some best practice tips for administrators managing changes over time.
- Changing these elements in an established form will negatively affect past ticket data, they should be kept static once in use:
- Consider the impact of changing a field condition set
- SLA timeframe changes will apply eventually
- Form field types
Changing the type of a field in an established form is a major data change.
It is not recommended to change a field type once in use. Doing so will break the database references to past data that was under the old type meaning it will not appear in InfoCapture filtering or reports.
The alternative is to create a new field in the form instead for your new purpose.
- Symbolic names
Used to distinguish between fields in the database, the alternatives to changing the symbolic name is to simply update the label of the field (and leave the symbolic name as it is) or create a new field for your purpose.
A warning explaining this further will appear in Claromentis v8.11+ when attempting to edit the symbolic name:
If you do update the symbolic name of an established field, expect to have to rectify form logic in your form following this, which could be time-consuming based on the complexity of your form.
Further to this, previously submitted data in that field can no longer be referenced e.g. in IC filtering, searches or reports which cannot be rectified unless the latest form version is deleted and the form reverts to where the symbolic name was not updated.
- Select field option values
Adding in new 'Select' options and labelling their values consecutively based on the other options is fine to do.
However, changing the values of the options around is not recommended as it will cause issues in the database.
The value is used to denote the selection of that option, so if this has been used in the form in ticket submissions but this value is then changed and checked in for new tickets, the previous references to this option will not be retrievable.
It is necessary to only add new options with increasing value as mixing this around means values are easily overridden in the database, and this is very tricky to unpick.
- Consider the impact of changing a field condition set
Field conditions are true or false statements that we can use to define how the form should react in those situations.
Depending on the complexity of your form, there could be hundreds of field condition sets to maintain.
Every time a form is submitted or edited, the system will check which conditions have been met so those that are active need to be correctly applied to ensure your form works how you expect.
For any update to field condition sets, the knock-on effect of this needs to be considered and any further changes planned and put into place to ensure the form continues to function as required with no disruption to users.
The working world is dynamic so responsible users may need to make tweaks to your form over time, including field condition sets.
If the changes needed for your form are quite drastic, consider creating a new form for this purpose instead to ensure the current one is unaffected by the need for mass modification and your users can still use it whilst others are being developed.
Reminder: You can export a whole form for re-import to use for testing purposes, or in this scenario act as a starting point to build on and create a new form.
If you wish to make changes to field condition sets, review what the condition includes and check if this is being used anywhere else in the form as those areas may need updating also in line with your needs.
Ahead of changing a field condition set confirm its title phrasing so you can identify it.
Next, work through each tab on the admin side to look for instances where the condition(s) is being used:
- Triggers
- Field Visibility
- SLA
- Automatic changes
- Workflow
- Notifications
You can search each tab page for the field conditions phrasing to speed up this process!
Anywhere the condition has been included will need to be considered for an update itself based on the change you are making and your forms needs.
e.g. In this example, if the conditions in 'Type = Enhancement' were to be changed, looking through each element to check where it has been referenced, this will have a knock-on effect on...
...the field visibility set it's used in...
...as well as the notification trigger it's tied to:
Based on the new conditions being applied, each element that references it may need to be updated to ensure the logic of the form still works as you require.
The areas that will need updating will differ per form and the updates made to its elements will depend on your company's needs for it, which is why it's best to check out field condition sets and how they are used across a form before making updates to them.
- SLA timeframe changes will apply eventually
Making changes to the SLA timeframe requirements will apply to all tickets but not immediately. e.g. Updating the SLA rule highlighted below to be 1HR instead of 3HRS.
New tickets submitted will follow the updated rule and change after 1HR but past tickets in the form will need some kind of interaction to rectify (where applicable) e.g. editing and saving it, status change etc.
Outside this past tickets submitted before the changes should update when the background task runs (which is every day at 5 AM)
Therefore if you make changes to SLA timeframes it is best to wait at least 24 hours to check past tickets update as expected and if they do not after this period, let us know in a support ticket.
Next recommended article
Investigative tools
