When processing eKeyRequests, the method varies somewhat based on the setup of KeyNET. For an eKeyRequest to be processed correctly, the following things must be true for a key to be issued correctly; specifically:

* The blindcode must be in the databsae

* The appropriate core location must be assigned to the blindcode

* A hook at at least one key issue point must be defined for that

blindcode.

Without the above things, the process of issuing a key really cannot occur.

In addition, for a specific request/issuance to happen:

* A key must be available on the hook

* The person to receive the key must be in the personnel database.

Consider a standard KeyNET system without eKeyRequest. What happens?

1. A person comes to Key Issue to get a key.

2. The operator starts in the person's personnel record. If no such record

exists, the operator creates one.

3. The operator goes to the key issue screen from the personnel record.

4. The operator looks up the location to find a key

5. The operator verifies authorization to issue the key from a paper form

6. The operator selects a physical key issue sequence to be issued

7. The operator issues the key to the human, whereupon the key is attached

to that person's personnel record.

Look closely at step 2. If a personnel record already exists, it is chosen by the operator. If no such record exists, the operator creates one.

In "slaved" situations, where KeyNET receives personnel data from another system via a transfer utility, this procedure is essentially the same. Whether the operator creates a record in the absence of one or not is really a policy decision made by the customer.

Now consider an eKeyRequest.  Although subsets of functionality can be used, in a fully-functional environment, here are some common scenarios:

*** eKeyRequests CREATED BY DEPARTMENT or BUILDING REPRESENTATIVE ***

In this scenario, a person with access to KeyNET, who is a member of the channel "init" group, such as a department secretary or building manager, requests the key on behalf of the employee.

1. The trusted human creates the request. The request contains:

* Field 0008, person, specifying the actual person in the

database to receive the key, as a REQUIRED field.

* Field 0033, the building,

field 0007, the room, and

field 0034, the department, for the key (if you are using building authorizations this field can be omitted).

2. If the recipient is not in the personnel database of KeyNET, the request cannot be created, and the trusted human can optionally add a new personnel record for the recipient to the system, depending on policy.

3. The request traverses the channel, finally notifying the trusted human

that their request has been approved. The trusted human sends

the recipient to key issue (or they can be notified via email if this feature is configured).

4. The person comes to Key Issue to get the key.

5. As the person has no paperwork, the key issue operator looks for an

approved eKeyRequest. The operator clicks the -completion- action

which links right in to that person's key issue screen.

6. The operator selects a physical key issue sequence to be issued

7. The operator issues the key to the human, whereupon the key is attached

to that person's personnel record.

In a "slaved" situation, this procedure is essentially the same, except that the recipient should already be in the KeyNET database.  That information being imported and updated from imported tables from other databases.

*** eKeyRequests CREATED BY KEY ISSUE OPERATOR ***

In this scenario, a person who wants a key just shows up at Key Issue with no authorization.

1. The person shows up at Key Issue to get a key.

2. As the person has no paperwork, the key issue operator looks for an

approved eKeyRequest. Finding none, the person pulls up the

person's personnel record. If no such record

exists, the operator creates one.

3. The operator goes to the key issue screen from the personnel record.

4. The operator looks up the location to find a key

5. Since it is already known that no authorization exists, the key issue

operator clicks the link to initiate the eKeyRequest. Any additional

information is added to the request as desired.

6. The request traverses the channel, finally notifying the initiating operator

that their request has been approved. The initiating operator calls

the recipient back to key issue.

7. The person comes to Key Issue to get the key.

8. As the person still has no paperwork, the key issue operator looks for an

approved eKeyRequest. The operator clicks the -completion- action

which links right in to that person's key issue screen.

9. The operator selects a physical key issue sequence to be issued 10. The operator issues the key to the human, whereupon the key is attached

to that person's personnel record.

As before, in a "slaved" situation, this procedure is essentially the same, except that the recipient should already be in the KeyNET database.

*** eKeyRequests CREATED BY UNKNOWN SOURCE ***

Now that we've described the trusted methods, here's how the system deals with an UNTRUSTED method. This is any scenario in which a NON-KeyNET USER initiates a request. Remember: If they ARE a KeyNET user, they are already in the KeyNET personnel database, and should log in to create their request.

If they are NOT a KeyNET user, they can only initiate requests through a trusted human (above scenarios) or via an untrusted web form.  Here's how that would work:

1. The web form is used to submit the request. The form might contain:

* Field 0033, the building,

* field 0007, the room, and

* field 0034, the department, for the key.

* Plain text fields (0064-) to accept the user's first and last name, EID, SSN, etc.

* Field 0005, the email field, to accept the submitter's email address.

The form CANNOT contain:

* Field 0008, person, specifying the actual person in the database to receive the key because at this stage the person may or may not be in the KeyNET database, but their identity cannot be positively confirmed (since the form is coming from the outside world.) But the CHANNEL -WILL- use this field, as an INTERNAL field, for follow-up processing.

2. The form is submitted, and goes to the first stop, some type of trusted human or humans who is/are KeyNET user(s).

3. The trusted human locates the person's EID in the submitted form, and

attempts to SAVE it into the internal Field 0008 field. If

successful, the EID was valid, the person's name is displayed next

to it, and can be compared to the submitted data. If NOT

successful, the person does not exist in the KeyNET database. The

operator can either add the record, or reject the request,

depending on policy.

4. The request traverses the channel, finally notifying the submitted email

address that their request has been approved.

5. The person comes to Key Issue to get the key.

6. As the person has no paperwork, the key issue operator looks for an approved eKeyRequest. The operator clicks the -completion- action which links right in to that person's key issue screen.

7. The operator selects a physical key issue sequence to be issued

8. The operator issues the key to the human, whereupon the key is attached

to that person's personnel record.

Again, in a "slaved" situation, this procedure is essentially the same, except that the recipient should already be in the KeyNET database.

Be sure and read the section on Web Form if you are using the UNTRUSTED method of eKeyRequests.

Note that the presence of the record in the KeyNET personnel database does imply a certain level of legitimacy to the request. It doesn't cause automatic approval, but it does prevent arbitrary rejection. Therefore, the automatic addition of records from an untrusted source is even MORE inadvisable than common sense itself should dictate.