eKeyRequest from the Web

eKeyRequest is a licensable add-on to KeyNET PRO, but is included with KeyNET ULTRA.  When licensed, eKeyRequest provides a number of customizable methods to use this AUTHORIZATION add-on.  This page describes the HTML required to produce an eKeyRequest from the WEB.  This method allows anyone who can access the web-form to request a key electronically.  The form is also highly customizable allowing a customer to create and arrange fields to be used in completing the request form.  KeyNET tracks the entire process so that individuals receive email at each stop along the authorization process; or authorized personnel can view the CURRENT status of each eKeyRequests.

A link to MY REQUESTS is available to all users with login privileges.  This feature allows a user to view their entire eKeyRequest history and the current status of those requests.

Authorizers will see another link called "List", which allows the Authorizer to see those eKeyRequests which still require action and the location of the eKeyRequest.  An Authorizer then has the ability to deny the issue, return the request for more or different information, or approve it and send it on to the next level for authorization.  Each step of the process is time and date stamped for historical recovery.

System Managers Setup - CRITICAL INFORMATION

When setting up eKeyRequests, there is a field named "User must have an account", this field is set to "yes", each user must also be set so that they may login.  

When you choose "no", the system will accept eKeyRequests from specially-configured forms that may exist elsewhere on the customer website, and which can be filled out by anyone, without requiring a user account and/or a user login.  KeyNET will not automatically generate such forms - Spectrum Group will created the form for you or provide you with the HTML format for your use.  System Managers can generate eKeyRequests - but setting the field to "no" tells KeyNET to accept submissions from such forms.  When set to yes, KeyNET will only accept requests from its own, internally-generated-for-a-logged-in-user form, and not from external forms.

Be sure and follow the Special Systems Notes at the bottom of this page during setup of eKeyRequests.

Setting up the HTML:

e-KeyRequest is an OPTIONAL and powerful feature which can be licensed in KeyNET.  It is designed to automate the requesting of keys and the obtaining of  authorizations for keys (or other assets) to be issued.  This module is email intensive.  No processing takes place without sending email and performing the associated tracking.  Your System Administrator will determine if email addresses are restricted to your facility, or if they may be Global.  Typically, email addresses are restricted to a facility, and users may only use addresses with the same facility (i.e., @KeynetU.edu, @keynet.k12.ca.us @knhospitals.org, knmil.net, or @gemco.gov)

Requesting a Key (or other asset) - In most cases, a link will be placed on your facility website which will take the web user to our AUTO-JOIN web-page.  The User will be presented with a login using their  USER ID, and Password.  In ALL cases...the User ID is the individuals complete email address, and the associated password will be a word of their choosing. 

System Users at the Department level who have been granted PEOPLE privileges may also enter information for other individuals.  This common practice is used by Department and School Secretaries to maintain the information database for those at their site.

If the individual information of the person requesting keys is not in the database, the information my be added by a PEOPLE USER or the system will AUTO-JOIN the person (if eAuto-Join has been licensed), sending their information to the appropriate DEPARTMENT AUTHORIZER they have indicated they belong too.  The department will approve or deny the fact that this individual is associated with their department. If the department recognizes and acknowledges that the NEW requestor is part of their department, a email will be sent to the REQUESTOR, informing the requestor that it is OK to request keys. If the department refuses to recognize or allow issuing through their department, an email will be sent to the REQUESTOR, informing the requestor that department will not allow items to be issued to them through that department.

If the individuals information is in the database, the system will prompt the person for Building and Room(s) to which they require access.  When the Key Request is complete, the requestor simply clicks on the SUBMIT button, and the request will be routed for proper authorizations.

Authorization Routing - eKeyRequest are routed based on the assignments of keys in the LOCKSHOP portion of the program.  However, the actual assigning of the authorizations is performed from the Authorizations Area of the People portion of the program.  The routing is made to the individuals who are authorized to approve access to those areas being requested.

• The first stop in the process should be defined as a "Department" stop.  SYSTEM CHANGE (May 7, 2005), department authorizations are no longer sent to the person named in the code table for that department. This worked fine when there was only one authorizer, but customers we asking for more than one department authorizer. So, department authorizers have been removed from the code table, and the department authorization workspace module has been removed from the workspace system.
  
  Department stops now work exactly the same as other stops. People who are department authorizers now get added to the department stop as stop members, just like any other stop would be set up. These individuals then automatically inherit the ability to add that stop to their workspace, just like any other stop member could add their stop to their workspace.
  
  The only difference now is that, for department stops:
  1. Only those stop members whose personal department (as set in their personnel record) matches the incoming request will receive arrival alerts (and department stops are still always set for arrival alerts in version 1.)
  2. Only those requests whose departments match the user's personal department will show up in that user's workspace module for handling.
  
  This is the first filter in determining if the requestor should actually have the key.  If approved, the approver simply sends the eKeyRequest to the next level.  If denied, the requestor will be notified via email that the request has been denied.

• If the eKeyRequest is approved and MKI is being used, the request will be electronically forwarded to Key Issue if keys are available.  If keys are available, the request can be forwarded for the final authorizations. 

• Should you need multiple places to complete the eKeyRequest, that feature is set up by your Systems Administrator in the eKeyRequest Channel Management.

• If the eKeyRequest is denied, and email will be sent to the requestor informing them that the request has been denied.

Processing the Key Request -

• The eKeyRequest when submitted will be routed to the first stop in the chain of authorization as created by the Systems Manager in the eKeyNET Channel Management portion of the program.

  Spectrum Group recommends that the first stop be configured to be a "Department" stop.  This will allow preliminary approval or denial of keys, and will make give  subsequent authorizers the benefit of knowing that others have performed their checks and balances before sending the request on to them. 

  NOTE: Department Authorizations are predefined by your Systems Manager entering an email address in the Code Management portion of the program under "Departments".  Each Department has one email address available for preliminary approvals.

• Further authorizations are defined in the Channel Management under eKeyRequest Configuration and using the "Configure Channel Path".

• When the eKeyRequest has come to the last stop in the path - it should be at a Key Issue Point.

  • Systems with ONE Key Issue Point.  All eKeyRequests will end up at this Key Issue Point.  Issuers can then fill the request if keys are available on the hook.  If keys are not available on the hook and key issue is in another location, away from the lockshop, they should use the eKeyOrder feature to obtain additional keys.

  Spectrum Group recommends setting a low inventory limit for each KeyID, thereby reducing or eliminating the possibility of no keys being available at the time of a request being made.

  REMEMBER: The low inventory can be set for an entire masterkey system during the initial development of the system.

  • Systems with Multiple Key Issue Points (MKI), have a set of hooks specifically for each MKI location.  eKeyRequests are then processed and completed at that MKI site.

  • eKeyRequest are handled at the local level.  Yet, the Lockshop and Systems Administrators have oversight, audit and reporting capabilities.

  Many facilities choose not to allow Department Masterkeys to reside at the Department level.  Typically, a key must be Authorized by by someone above the level of key being issued.  Therefore these facilities require an Authorization above the Department level for a Department Master.

Notifications - when configured, an email notification will be sent to the appropriate individuals who are associated with the eKeyRequest.  The originator is always notified of approvals, and Authorizers are notified via email when there is an authorization in KeyNET which requires their attention.

If you have this feature, please refer to the documents provided to you by your instructor at the time of training or your training video.

Some special notes about this system:

1. System administrators who add the department stop to their workspace will see ALL requests, regardless of which department the request or the system administrator belongs to.

2. Users who are members of a department stop MUST have a department set in their personnel record. If they do not (and they are not system admins) they will not see ANY requests or receive ANY alerts for incoming requests at that stop.

3. In version 1 channels, e-key requests require the entry of a department.  Department authorization stops, however, can now be used in normal channels as well. In those cases (and in version 2), if you're going to have a department stop, you want to ensure that entry of a department field is REQUIRED to ensure that requests to vanish (going only to system admins without email alerts) when those department-less requests hit the department authorization stop.

If you need copies, contact Spectrum Group at support@sg1.us or 877-560-2457