Assurance is a workflow management tool that is designed to ensure that key elements of your organisation’s policies ‘come to life’. This article will you give an overview of the key features in Assurance and explain some of the common terms that will be used throughout the platform.
In this article, you will learn about:
Registers and Forms
Assurance allows you to submit Feedback, Risks, Incidents and more through a Form. They can be separated into various Registers. For example, you may have a Register for Feedback and Complaints, one for Macro Risks and another for Incident and Breaches.
The common terms that you will encounter when using Registers and Forms include:
- Fields: A Field is a question on the form in which you can enter data. For example, an Incident Form may have a field for when the incident occurred, who is reporting the incident and a description of the incident etc.
- Key: Every Form will have a field called Key. This field is automatically filled out by Assurance when a new Form is created in that Register. It is used as a way of easily identifying a Form. We make no guarantees that key numbers will be incremented sequentially without gaps. You should not rely on the Key for anything else besides an identifier for the Form.
- Person Responsible: Every Form will have a field for the Person Responsible, which is the User in Assurance who has ownership of that record. This field is important as it has certain functionalities attached to it, such as notifications around End Dates for contracts.
- Stages and Workflow: Registers can be set up with a Workflow which Forms created in that Register will move through. Each step in this Workflow is called a Stage.
- Approver: You can set up a Register Workflow to require User Approval before moving to the next Stage or before being closed. The User who is required to approve is called an Approver.
- Eligibility Criteria: Certain contracts may require the counterparty (supplier, contractor, or service provider) to have specified credentials. Typically, these include insurances such as professional indemnity insurance or public liability insurance but may also include service provider-specific credentials such as working with children checks, police checks or qualifications. In Assurance, these requirements are called Eligibility Criteria.
- Merge Doc: A Merge Doc is a Word Document that contains several Merge Tags in it that correspond to specific fields on the Template. You can then go to a Form and generate this Merge Doc as a DOCX or PDF and the Merge Tags will be replaced by the data in those fields. Typically, this is used to generate either contracts or standard letters to counterparties. However, this can also be used for example in an Incident Template to generate an Insurance Claim Form without having to fill out the form manually.
- Public Link: Each Register can generate its own Public Link. This Link can be placed on your website or intranet and allows anyone with the link to fill out and submit the form without being a user of Assurance. Examples of Public Links include an Incident Form or a Feedback Form.
- Launch Pad: Public Links can be grouped together into a single Launch Pad. This is a page that contains several Public Links. This can be placed on your website or intranet instead of individual Public Links.
Actions or Tasks
Actions are tasks that need to be completed by a User and can be set up either as s one-off Action or recurring Actions. Actions can have priorities and have pre-set responses when a user is completing them (e.g., Completed, Cannot Complete, In Progress). A User may also need to provide comments or upload evidence when completing an Action.
The common terms that you will encounter when completing Actions include:
- Action Assignment: A single Action can have multiple Assignments made from it to different Users, and each Assignment is an individual task to be completed. For example, you may have a Conduct Site Inspection Audit, this can then have several Assignments made from it for each site.
- Person Responsible: Every Assignment will have a field for the Person Responsible, which is the User in Assurance who needs to complete that Assignment. This User will also receive notifications around the Due Date of the Assignment.
- Escalation: If an Assignment passes the Due Date without being completed, you can designate Escalation Users who will be able to complete the Action on behalf of the Person Responsible.
- Action Results: Every Action Assignment has a corresponding Action Result. This shows the responses to the Action, as well as the history of the Result, what evidence and comments were made etc. For recurring Assignments, each recurrence has an individual Action Result.
- Action Response: When responding to an Assignment, there are pre-set responses. By default, the responses are Completed, Cannot Complete and In Progress, but these can be customised. At the very least there needs to be a response for assignments that are in progress, completed or that cannot be completed.
Checklists
Checklists are collections of questions that are assigned to a User to complete and can be set up either as a one-off Checklist or recurring Checklists. For example, you may have a monthly performance report with a set of questions for someone to complete, which can be set up as a Checklist in Assurance. Another example would be the use of a Site Inspection Checklist which would repeat monthly. Checklists can also have Review Stages, which have their own set of questions for a Reviewer to complete once the Checklist is completed.
The common terms that you will encounter when completing Checklists include:
- Checklist Assignment: A single Checklist can have multiple Assignments made from it to different users, and each Assignment is an individual Checklist to be completed. For example, you may have a Monthly Performance Report, and create Assignments from this for each of your Service Providers.
- Person Responsible: Every Assignment will have a field for the Person Responsible, which is the User in the system who needs to complete that assignment. This user will also receive notifications around the Due Date of the Assignment.
- Escalation: If an Assignment passes the due date without being completed you can designate Escalation Users who will be able to complete the Checklist on behalf of the Person Responsible.
- Checklist Results: Every Checklist Assignment has a corresponding Checklist Result. This shows the responses to the Checklist Questions, as well as the history of the Result, what evidence and comments were made etc. For recurring assignments, each recurrence has an individual Checklist Result.
- Review Stage: A Checklist can have multiple Review Stages set up. Each Stage has its own set of questions and reviewers. When the Checklist Assignment is completed, it moves to the first review stage, when the first Review Stage is completed, it moves to the second, and so on.
- Reviewer: Every Review Stage has its own Reviewer, which is the User in Assurance who needs to complete that Stage. This User will also receive notifications around the Due Date of the Review Stage.
Entities and Contacts
Entities are counterparties to your contracts - they can be Lessors/Lessees (in leases), Contractors, Suppliers, Consultants, Funders etc. Contacts are the various key contacts of those service providers.
Common terms around Entities and Contacts include:
- Lite User: Lite Users are special types of users that can be linked to Entities or Contacts. Lite Users are limited in what they can do in Assurance. Namely, they can only respond to Actions or Checklists that have been assigned to them.
- Credentials: Forms such as contracts can be set up with Eligibility Criteria. This requires Entities and Contacts to have certain Credentials before the Contract can go ahead. Typically, credentials are used to collect insurances (such as Public Liability or Professional Indemnity Insurance) from entities. In some cases (such as in health service provision), it can be used to collect credentials for the individual contact of the organisation that is providing services - for example, in the case of an Allied Health Provider providing services to children, they may require a Working with Children Check.
Miscellaneous Terms
Other miscellaneous terms that you will encounter in Assurance include:
- To Do List: Every User in Assurance has their own To Do List which shows what items require their attention in the next 30/60/90/180 days, depending on their settings. This includes Action, Checklists, Expiring Forms, Forms awaiting their approval etc.
- Dashboard: There are several dashboards in Assurance that contain snapshots for assessing the information currently in the system. There is the Home Dashboard (which includes the To Do List), the Forms and Registers Dashboard and the Risk Dashboard.
- Snapshot: These are collections of data such as graphs that can be used to report on the information currently in Assurance. For example, the Forms and Registers Dashboards have a graph for Open Forms over a period, Closed Forms over a period, Average Days a Form waits for Approval etc.
- Business Unit: Business Units can be used to represent your organisation's structure. This is important as many features of Assurance can be driven by Business Units, such as Access Rights, an Approval Workflow, Reviewers for a Checklist etc.
- Access Rights: A user's Access Rights determines what parts of Assurance they are allowed to see. This is broken down into the various features of Assurance, i.e. Forms, Actions, Checklists, Entities and Documents.
- Access Role: A particular Access Right is called an Access Role, e.g., giving a user Read Rights for Feedback and Complaints in Assurance. These can be further broken down by Business Unit, i.e. only Feedback and Complaints that are in their Business Unit.
- User Profile: A collection of Access Roles can be grouped together to make a User Profile. This Profile can then be applied to several Users that need the same Rights.
Comments
0 comments
Please sign in to leave a comment.