KMS - UserId & Password Procedures

KMS UserId & Password Procedures

General Information

When agencies setup new users, the id is created in two places, KMS and a secondary software called Lexipol ID. The agency admin is only responsible for the KMS setup. Provided the KMS side is entered correctly and has no issues, the Lexipol ID is automatically generated. The UID and LID must match for the account to reconcile at login.

NOTE: If there is an issue with the setup, and corrections are needed, the system may not allow it because those revisions are not translating to the Lexipol ID side.

Please do not disable or delete users! Please reach out to Lexipol Customer Support or open a Customer Support ticket to have it corrected. Even if the profile is corrected in KMS, the Lexipol ID side cannot be corrected by the agency and the user will not be able to log in. Deleting users and re-adding them will typically just give an error indicating that the account already exists and cannot be created. If it does allow you to create the account, it just creates problems and multiple instances of the user.

Passwords

User Password Requirements

Minimum 8 characters, 1 Capital Letter and 1 number or special character.

How to Reset Passwords

1. Go to the Admin tab.

1. Go to User Management, search for the user. You can search for users by all the fields in the screenshot but usually Last Name or Email are used.

1. Go to the pencil to open the User Profile

1. User Information Tab

   1. Update Password – The asterisks in the Password and Confirm fields are prefilled (usually you will only see the asterisks when it’s a Password Update). Enter Policy123 in both fields and remove the checkmark from “Password Not Expired”. When the user enters Policy123 (temporary password), they will be immediately prompted to enter a new password. The admin needs to notify the Users of the temporary password. Agencies can use whatever temporary password they choose if it meets the 8-character requirement.

User Setup

Adding New Users

Agency admins, in most cases, should be responsible for setting up users. Customer Support does not typically setup users. Maintaining the profiles is part of the responsibility of the assigned agency administrator(s). As previously noted, if problems are encountered, please contact Lexipol Customer Support for assistance.

NOTE: Initial implementation to establish users for a new agency in the onboarding process can be handled by Lexipol.

How to Add a User -

• Within KMS: Click Admin Tab > User Management > Add user.

User Information Tab:

• Primary fields: Email, First Name, Last Name

• All other fields are optional, but attention should be given to the following fields:

  • Groups - If groups are utilized then the user MUST be added to the correct group at this time as it possibly dictates how policy is distributed.

    • Important to note that this field DOES NOT remain populated. So once the profile is submitted, when viewed this field appears empty.

  • DTB Start Date – MUST BE present (if agency subscribes) as this determines how DTB’s are received initially and if left blank DTB’s will not be received at all.

• Set Password – The initial password MUST be set when creating the user profile. If not set, the account will not fully create and no Lexipol ID will populate. Lexipol uses a standard Policy123 (case sensitive) for this field and this prompts the user to set a new password at login.

• User Status –

  • Account Enabled - auto checked field.

  • Password Not Expired - must be unchecked, this prompts the user to set a new password at initial login. (see diagram above)

  • DTB Test Taker – MUST BE checked if the agency is doing Daily Training Bulletins (DTB’s). Again, this must be checked, and the user must have a DTB Start Date, or they will not get DTB’s.

• Notification Settings – choose Mobile, Email or both (this allows the user to be notified of Acknowledgements and DTB’s)

Re-enabling a User

Users removed from the roster go to the Not Enabled list of users. To enable a user that has been removed:

1. Go to User Management

2. Change Account Status to “Not Enabled”

1. Search for the user.

2. Edit the user.

1. Enable the user and then Submit (you cannot update any other information in this step!)

1. Check the enabled list and be sure that the account is there and that it has a UID. If that all looks good, then re-enter the profile to make any necessary changes. Update Password and remove the checkmark from “Password not Expired”.

2. Submit.

Correcting Users Created without a UID

If the initial Password is not entered during setup the profile is created without the UID. This means the profile is incomplete and the user will not be able to login. If this occurs it take two steps to correct:

1. Opening the user profile and submitting will usually create the UID. If it does not, then there is an issue with LID, and you will need to reach out to Customer Support. Once corrected, then proceed to step 2.

2. Go back into the profile, Update the Password to Policy123 (case sensitive) and remove the checkmark from “Password not Expired”, Submit. The user should now be able to login and will be prompted to enter a new password at initial login.

NOTE: If there is still an issue, please contact Customer Support for assistance. Deleting and readding the user is NOT the answer. Allow us to assist.

Domain Changes

Please reach out to Customer Support to assist with Domain Changes. There are a lot of intricacies and attempting to adjust the domains can often cause problems.

Re-Using Email Addresses -

This is not a practice that Lexipol advocates. Some agencies have general addresses that are owned by the agency, and they use those versus personal email addresses. When an officer leaves the email is available for them to re-use.

Important to understand why we don’t agree with this action:

• Legal issues – If there is an investigation of an officer, there is no reliable audit trail once the email is reused.

• Training – If the user was a member of one of the verticals (Police1, FireRescue1, EMS1, etc.) and completed courses, the training records are compromised. This cannot currently be fixed.

User Permissions Tab:

When new users are setup the permissions for that user have to be added. This is on the second tab called Permissions. Setting the user permissions is what dictates what accesses the user has and what policy/procedures get delivered to the user. What policy/procedures they receive can be further designated by Policy Groups which we will look at in the section: Policy Groups and Scheduled Acknowledgements.

Choosing the appropriate permissions for the user:

Explanation of User Permissions

Agency Administrator

Highest Level of permissions. Grants full authority to complete all functions related to KMS: Policy/Procedure manual editing, releasing policy, collaborations, DTBs, and setting up users within the account.

Agency admins should also be given the Product Specific User level permissions (i.e. LE User, Supplemental User) to ensure visibility on the Acknowledgement reports. This is all encompassing and there is NO reason to checkmark all the permissions which can potentially cause permission issues.

(Product) Agency Administrator

Grants full administrative authority to the product specific manual, DTBs and user setup.

Example:

Custody Agency Administrator grants full admin rights to the Custody manual and Custody DTBs, only. However, this user has access to all reports and users regardless of the assigned product.

Product Specific User level permissions to ensure visibility on the Acknowledgement reports.

Note: If a user is an admin of one product and an end-user of another, the end-user

box of the other product needs to be checked.

Example:

Custody admin user is also an end user of the LE manual, but does not need to

complete LE DTBs, LE manual user must also be checked.

(Product) Agency Analyst

Allows access to run all reports, for all manuals and DTBs the agency may have, regardless of product type.

Product Specific User level permissions to ensure visibility on the Acknowledgement reports.

Example:

Fire Agency Analyst provides access to LE, Custody, and Supplemental manual reports as well. No access to user management.

Do not select this box alone or the user will not have access to receive and view policies.

(Product) Agency Author

Allows access to edit and approve policy within the specified product manual, but

they cannot issue policy.

Product Specific User level permissions to ensure visibility on the Acknowledgement reports.

Example:

Fire Agency Author allows the user to edit fire policy, only. However, this user will

have editing and issuing rights to all DTBs but does not have access to reports, user management, or accreditation tabs.

(Product) Manual Administrator

Allows editing and approving rights to the specific product manual, only, but not authorized to issue policy.

Product Specific User level permissions to ensure visibility on the Acknowledgement reports.

Example:

LE Manual Administrator allows editing rights to the LE manual, only. It does not allow access to reports, draft DTBs, and user management.

(Product) Manual Author

Allows editing rights to the specific product manual, only.

Product Specific User level permissions to ensure visibility on the Acknowledgement reports.

Example:

Supplemental Manual Author allows the user to edit only the supplemental

manual. User cannot issue policy and has no access to draft DTBs, reports, accreditation, and user management.

(Product) DTB Administrator

Allows full rights to all DTBs, regardless of product type. Does not allow access to reports,

accreditation, or user management. It does not allow access to reports. To run reports the additional permission of Agency Analyst should be granted.

(Product) DTB Author

Allows full rights to all DTBs, regardless of product type. User can edit and issue all DTBs.

No access to reports, accreditation, and user management tabs. To run reports the additional permission of Agency Analyst should be granted.

(Product) DTB User

If checked alone, the user will not have access to the manual or DTBs. When checked in addition to manual user, user will have access to both the issued manual and issued DTBs. This permission is not necessary if the DTB Test Taker Box is checked, and the user has a DTB start date on the User Information page.

(Product) Manual User

Allows access to the issued manual for the specific product. User will receive and acknowledge product policies but does not get DTBs.

(Product) User

Includes same permissions as DTB User and Manual User, therefore, this is the only permission needed to provide the user with the ability to acknowledge policy and complete DTBs. DTB start date and the DTB Test Taker box MUST be checked on the User Information page. This is specific to the product type.

Example:

Fire User provides access to issued fire policies and fire DTBs.

Note: Users with higher permission access (i.e., Authors, Analysts, and Manual Administrators) will need access to the User or Manual User functions.

Exception: The Agency Administrator still needs to have a DTB start date and DTB Test Taker box checked if the administrator will be required to complete DTBs.

Once the choices are complete, Submit and the message comes up that the user was successfully created. If the Submit button does not come live after all fields are entered, recheck the password fields to be sure they were entered accurately.