We appreciate there is a lot to get to grips with in InfoCapture and its particular mechanisms will become familiar with the experience.
Below are some best practice tips for administrators or responsible users investigating issues raised by end-users in InfoCapture.
- Confirm user access to forms via project roles
If a user reports an issue with InfoCapture the best place to start is to check they actually have permission to view it in the first place.
Check the project role permissions on the admin side of the form and look for that user being specified directly or a People role/group they are in being used.
If they are not specified or included in the roles/groups used, then this is the reason why they cannot access the form.
- A user cannot perform a certain action? Check their rights
Check they are included in permissions for the form as above.
If they are specified, next check the 'Rights' tab to confirm the project role they are in has permission to perform the action they expect.
If not, give them the required permission in the table and save this to resolve.
If it's not appropriate for the role they are in to have this ability then you can make further edits to your form to encompass this in a more suitable way. e.g. A new project role to include and differentiate users with these abilities
- Check the history tab
The 'History' tab gives an overview of all changes taking place in or to a ticket over time.
This is really useful when investigating issues as it's essentially an audit log of events specific to that ticket.
It shows in black and white whether a change took place, a field was edited, an SLA was breached etc. in chronological order.
Use the History tab to determine facts about a ticket over its lifetime and draw conclusions about why something you expected to occur may or may not have as well as how to rectify this in your form.
- Use the audit log to track if certain notifications were generated
One of the most common issues raised about InfoCapture is that a user did not receive a notification from a form when it was expected.
We have a detailed guide on how administrators can troubleshoot notifications and investigate.
To investigate in the first instance it can be confirmed with absolute certainty whether the issue lies with the form logic (i.e. a notification was never triggered for that user) or the notification was triggered and generated but not received by the user (i.e. indicating a server or user environment issue)
Utilise the audit log to check if the system generated a notification at the time it should have for the specific user and the appropriate ticket ID:
If there is something logged, then the form is working correctly and the issue lies with the server or the user themselves.
If there is nothing logged, then the issue lies in the configuration of the form and this will need to be investigated by your administrators or responsible users to identify what is preventing the notification from being triggered (more information in the notification troubleshooting guide).