|
Other aspects of the LOCKSHOP module are listed and linked
in the left hand column.
Items related to eKeyRequests are:
Request Methods and WEB Form.
OVERVIEW
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. Different from the Authorizations used in the main
program, eKeyRequest allows users to AUTOMATICALLY route authorizations to a Key
Issue Point, with stops at customizable authorization points. 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 or authorized personnel can view
the CURRENT status of each eKeyRequests.
A link to OWNED 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.
GETTING STARTED
Review the following eKeyRequest Methods to select the
eKeyRequest method which best suits your needs.
Before starting, insure that your Systems Administrator
has licensed and CONFIGURED your privileges to allow you all of the
features you will need from the eKeyRequest
Module.
eKeyRequest 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).
eKeyRequest History - it is now possible to configure a channel to
log the history of status and stop changes and pathway traversal.
To
enable history logging, the Systems Manager must select the "Status Gets Logged"
checkbox in the channel configuration screen.
Once selected, any status changes or stop changes made to any record in the
channel will be logged. Note that ALL status changes are logged, whether they
use a stop action, or whether the user just changes the status field in the
record. Information logged includes the date, time, old status, new status, and
adjusting user.
When this feature is enabled for a channel, each record displays a new section,
"Recent Status Changes," which displays, in most-recent-first order, each change
in status made to the particular record. A "View All" link allows the user to
pull the full history. Of course, history records cannot be manually added,
edited or deleted.... only viewed.
This provides the desired feature of tracking who did what in an eKeyRequest.
Once initiated, each person who changes the request's status is logged... so you
can see who did the department approval (changed from "Awaiting Approval" to
"Awaiting Key Issue") and who issued the key (changed from "Awaiting Key Issue"
to "Completed") or who cancelled the request, etc.
Requesting a Key (or other asset)
- There are
3 methods which can be used to initiate an eKeyRequest.
The requestor
must have an account -
the most secure and easy to manage
method.
The
request is made from a web-form that anyone can access and create -
harder to control, as anyone can submit a request. No login is
required
Use the AUTO-JOIN feature to
create an eKeyRequest -
the hardest to control and least
secure method of use. AUTO-JOIN uses the information from the web-form to
create people in your database.
When the
Requestor must have an account method is used. The requestor
must have an account and must login to KeyNET in order to make eKeyRequests.
The Requestor may submit eKeyRequests for others who may not have login
privileges (but the person for whom the key is requested must be in the database
before an eKeyRequest will be successfully created.
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. |
When the WEB FORM method is
used... a link will be placed on your facility website which will take the
web user to a web-form type web-page for submittal. To request a keys, the
user simply fills in the appropriate information into the web-form and clicks on
the SUBMIT button. The information from the web-form will be entered into
the eKeyRequest channel without logging into the program. Depending on how
your eKeyRequest channel is set up, notifications are sent to the individual to
whom the key will be issued, or the requestor as the eKeyRequest moves through
the Authorization Routing.
When the AUTO-JOIN feature to create an
eKeyRequest - the hardest to control and
least secure method of use. AUTO-JOIN uses the information from the
web-form to create people in your database. EXTREME CAUTION should be used
when using this method, because of the potential of unwanted users being added
to your system. Additional fees will be added to the annual license and
support contract when this feature is used to cover the additional
administration which will be required by Spectrum Group.
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.
-
Stop limits may be set to restrict stop members to Buildings,
Departments or Cost Centers.
-
When the first stop in the process is 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.
Stops now work exactly the same as other stops.
However, stop limits may be set to make the stop unique to Departments,
Buildings or Cost Centers. 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
building, department or cost center 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.)
-
SYSTEM CHANGE (October
1, 2005) There is no longer a specific correlation between the an
individuals information and stop membership, when stop limits have been set.
When adding a stop member to a limited stop (building, department or cost
center) a second field is now required which will make that individual an
authorizer for a specific building, department or cost center. In this
way an individual may be the authorizer for more than on building,
department or cost center.
2.
Only those requests whose
building, department, or cost center match the user's stop membership
personal
department will show up in that user's workspace module for handling.
-
SYSTEM CHANGE (October
1, 2005) if a stop is not limited (building, department or cost center) all
individuals listed as stop members will be notified of status changes (as
programmed in the channel).
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 -
ONLY
BUTTONS SHOULD BE USED IN THE AUTHORIZATION PROCESS!!! If the status field is
used during the process...the eKeyRequest will change appropriately, but will
not process successfully through the designed authorization process.
-
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.
Stop Methods
- now includes the ability to refer back to standard authorizations
for individual building and room authorizations.
Previously, stops
in a eKeyRequests could have "limits" set - limits like building, department, or
cost center. These limits, when activated for a stop, would allow stop members
to be added to a stop only for a specific instance of the limit type - in
other words, only for a certain building, or department, or cost center.
These "limited stop members" will then only receive stop-member privilege on
requests which were both at the stop AND which matched their limit setting -
in other words, they could only work on records which were set for their
specific building, or department, or cost center.
Now, a new stop
limit option exists, "KeyNET Authorizations".
This allows a stop
to be "slaved" to the KeyNET Authorization system which is not part of the
eKeyRequest channel.
In order to select
this stop type for a certain stop, the following conditions must be met:
1. The stop must
not have any stop members.
2. KeyNET must be
licensed.
3. KeyNET
Authorizations must be licensed.
4. The channel
must be a KeyNET type of channel (i.e. either an eKeyOrder or an eKeyRequest
channel).
When the above
conditions are met, "KeyNET Authorizations" appears as a choice in the "Stop
Limits" menu in the Stop Options screen. To make the stop a KeyNET
Authorizations stop, select "KeyNET Authorizations" from the "Stop Limits" menu,
then click SAVE.
Unlike other
stops, a KeyNET Authorizations stop does NOT have any stop members. Instead, it
is "slaved" (matched) to the "Authorizations" subsystem in the KeyNET module.
Stop members are added by adding individual authorizations to individual people
using the PEOPLE module.
NOTE: ONLY LOCATION-BASED AUTHORIZATIONS (individual
Building and Room authorizations) APPLY TO THIS STOP TYPE. "DEPARTMENT
WIDE AUTHORIZATIONS" IN THE KEYNET AUTHORIZATION MODULE DO *NOT* APPLY TO,
RELATE TO, OR GRANT ACCESS TO THE CHANNEL SYSTEM.
Department wide
Authorizations must still be set up separately using the "Department" Stop Limit
setting. This is done to more finely control which department authorizers
participate in the electronic process.
Once a user has at
least one location-based authorization on their record, they become stop members
of the KeyNET-based channels with KeyNET Authorization stops in them. They get
the ability to add workspace modules, and interact with the appropriate
requests. Lacking other access, they can (like all channel members) list
all requests, but they can only "go in to" and interact with requests which are
at the KeyNET stop, and whose location is one of their authorization locations.
From there,
everything else is the same:
* They will
receive emails about requests at their stop for their location (s)
* Appropriate
requests will show up in their workspace module (if used)
* They can
interact with appropriate requests using the process control
(stop actions)
as configured in the channel, including the addition of a
process
control comment if configured.
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
|
