Who is this article for?

Administrators who want to learn more about dashboards.

Administrator Access is required for some of these steps.

These FAQs provide additional details to help you better understand and use Lucidity Incident and its linked applications such as Lucidity HR and Lucidity Access.

Note: Make sure that you have the correct administrative access to perform the required task. The system administrator can assist with this.

1. A hazard has been incorrectly entered as an incident report. How can I change this?

There is no way to change an existing issue to a different issue type. A new issue will need to be raised and the incorrect issue deleted. 

It is recommended screen shots or reports of the incorrect issue are gathered prior to deletion so all information is transferred correctly.

2. How can I quickly locate the Issues I need to approve as a Responsible Manager?

From the issues register (List Issues page), use filters to only view issues with a status of Draft. Additional filters can be applied to only view those issues relevant to a particular business division etc.

3. How can I access the workflow to approve or closeout an Issue?

To access the workflow screen:

1. Go to the Issues Register, click Actions.

2. Select Workflow.

3. Once an Issue is opened, select Workflow from the menu on the left-hand side.

4. Once the Issue is opened, select the Workflow button within the manage screen.

4. Why did the selected contributing factor in the casual analysis not result in a corresponding action automatically?

• Contributing factors are set as either a root cause or as a finding in the Settings menu by system administrators.
• Actions are only created for root causes. If the selected contributing factor is a finding, this will not result in an action being created automatically.
• Actions can be created as a stand-alone action but will not be linked to the contributing factor.

5. How can I easily locate issues that have been set to 'No Further Actions Required?'

If an Issue has the option of no further actions required selected in the report, it will be automatically set to closed and no further management is required. These are easily distinguishable as they won't have the Manage option from the issues register.

6. How can I ensure particular issues are kept confidential and can only be viewed by select people? 

In order for select issues to remain completely confidential, select incident categories can be hidden from view from most end users. For this to be enabled, several steps need to occur:

1. Contact support to enable a feature called Incident Process Permissions. This features means a new privilege will appear in the Incident Access roles list called Process Manager.

2. Create a new Access role that includes this privilege only and assign it to

• Anyone that will be the responsible manager for these issues
• Anyone that will be the close out manager for these issues
• Anyone else that needs to view these issues

Note: The above people will also need the responsible manager and/ or the close out manager and/ or admin access role(s).

3. Educate general end users.

• Anyone can raise an issues with the Process category however only those with the newly created Access role can view them.

Note: This means even the person raising it won’t be able to view it once it’s created if they don’t have the permission and the end user MUST select a responsible manager that has the newly created role.

• Only the responsible manager with the access role will be able to view them. If an end user selects someone as the responsible manager who doesn’t have the permission, they will still get the associated notification but they won’t be able to view the issue

Note: Only those with the new Access role will be able to view, edit and report on these issues.

Note: This functionality can also be applied to the 'Drug and Alcohol' incident category.

7. My Incidents appear to have lost Actions associated to them. How can I avoid this?

On occasion, when creating and saving a high number of actions (more than 50) associated to an inciden, inspection or audit, the application and browser may not keep track of them and some will appear to be missing when the page is reloaded or viewed later. Though the actions appear to be lost, behind the scenes they still exist in the database. The reason they appear to be missing is that they have become disassociated with the incident. There can be a number of reasons for this to occur, but primarily we have seen it caused by poor internet performance or browser limits. Therefore, our recommendation is to limit the number of actions associated to an incident to no more than 50. We are working on improving the efficiency with which the Incident save process occurs, so that it can support connections to more actions.