B
The process starts with an authorized user logging into the site. The user may have one or more roles. The possible roles are User, Requestor, Coordinator, Functional Lead, and Banner Id Management (BIM).
These roles are defined as follows:
User: Employee seeking access to Banner.
Requestor: Employee’s boss.
Coordinator: The contact person(s) authorized to make Banner access requests for a particular campus.
Functional Lead (AKA Approvers): Individual(s) designated to review and authorize access to specific functions (i.e. Accounts Receivables, Fin.Aid, Student).
B
anner Id Management (BIM): Individual(s) that provide the technical support of establishing Banner access.
When an individual logs in, they may be directed to one of five locations depending on their role, or lack thereof. If the user has no role, they get an error message, otherwise they go to the page appropriate for their role. If a user has multiple roles, they will be directed to a page with tabs, where each tab handles a different role.
Here’s a high-level, typical-case, overview of the process as far as the site is concerned, details will be discussed in the appropriate section.
A Coordinator receives a request (via email, etc) for a new account from a Requestor.
The Coordinator logs in and fills out a form with the Requestor and User’s information, and submits the request.
Approvers are notified, as appropriate, that they have pending requests.
The Approver(s) log in and approve/deny the request.
Once all approvers have responded as needed, the User receives an email asking them to log in and approve a FERPA notice.
If the FERPA notice is approved, the BIM staff receive an email telling them an account request is pending.
When the BIM staff mark the request as completed, a notification email is sent to the User, Requestor, and the Coordinator.
For now, that is the extent of the system, although hopefully we can add in the ability to create/edit the requested account from inside the site as well.
The following sections will go through the actions of each role in depth.
C
After logging in, the Coordinator comes to a page with several options: create/modify account, view/edit a pending request, view all past requests, undo a past action, or view all past actions.
ToDo: add “show all past actions” form.
All pending requests (those which have not yet been marked as completed by BIM staff), are in the pending requests table. While all requests with completed status are found by clicking on the “View past requests” link.
The pending requests form shows the date the request was originally made, the full name of the user along with the campus association, the last action taken on the request and the date of that action, and a summary of the permissions requested. Note that names in the pending request table are links to detail pages about the user and their request. This is the same page the user is taken to should they click the Edit button in that row.
This page also contains a list of the most recent past actions taken by the current Coordinator. Each action has an undo button, and even undo’s can be undone. The Coordinator can also click the “View all past actions” link to get a comprehensive list.
Coordinator, Request New Account (c2):
To request a new account, the Coordinator enters the UH username of the User and clicks the “Create/Modify Account” button. The system checks to make sure this is a valid UH username and if the user has an existing account or not.
If the username is not found in either the BSAR database, or through an ldap lookup, the Coordinator will see an error message stating that there is no such UH username.
If such a username is found via ldap, but not in the BSAR database, the system knows this is a new account. The Coordinator will see the User’s information (username, first name, and last name), fields for the Requestor’s username (if different from User), classes/forms the User wants to access, and the campuses for those classes/forms, a means to mark the request as being urgent, and a field for entering comments. There is also a sub-form where the Coordinator can enter the username of another User and opt to copy that individual’s permissions for this account.
ToDo: Add form to show what happens when an account is copied.
If on reviewing the User’s information, the Coordinator discovers they have entered the wrong username, they click the “back” button to correct the mistake, otherwise, the user enters the Requestor username, selects the appropriate classes/forms and clicks “Submit”. If no classes or forms are provided, the default set will be assumed by the BIM staff.
Upon submission, the class/form fields are checked to ensure they are proper class/form names. If errors are found, the form is repopulated and displayed, along with an error message next to the offending entry. If all values are correct, the Coordinator goes to a confirmation page which displays a standard “Your request has been submitted” message, a summary of the request, and a button to edit the request should there have been any mistakes. At the same time the Coordinator is seeing the confirmation page, any necessary Approvers are being notified they have an action item.
Coordinator, Modify existing account (c2):
Changing a previously existing account starts off just like creating a new account: the Coordinator enters the UH username of the User and clicks the “Create/Modify Account” button. The username is verified and their account information is retrieved.
The Coordinator is directed to the same page as described in the “Create New Account” section above, but there are two differences: Along with the information and forms described for a new account, there are additional forms to show and modify existing and pending permissions.
Existing permissions consists of all classes and forms the User already has access to, the form level access (query or modify), and means to request removal of any, or all, of the permissions. This form is used only to modify or remove existing permissions, while new ones are entered below. Note: the existence of an existing permission form assumes that we can import existing account information into the new system’s database.
Pending permissions are requests for the current user that are not yet marked as completed by the BIM staff. If the request has already been forwarded to the BIM staff, no edits are allowed and changes must be done via a new request. This is because the BIM staff may have already executed the request, but not yet marked it as completed. If instead, the request has not yet been sent to the BIM staff, it is editable and the Coordinator can use this form to cancel pending requests or to go to a details page for editing. If the Coordinator made changes to existing permissions while setting new permissions, both parts are bundled into one request. Changes to pending permissions are handled as part of the pending request, and are not bundled with the others.
With the rest of this page, the Coordinator can create a new request. Upon submission, the request is checked to see if any approvals are required, and if so, the Approvers are notified. Since this is an existing account, the FERPA notice is already approved, so if no approvals are required, an email is sent directly to BIM staff.
ToDo: Should there be a button to “Cancel Account,” or is removing all permissions sufficient?
Coordinator, Change pending request (c2b):
If from the create/modify account page, the user selects the button to edit a pending request, they are taken to this detail page of the selected request. This page is only reachable when the request has not yet been forwarded to BIM staff.
From here, the Coordinator can cancel all or part of the request, or modify the requested permissions or urgency status. Note that no additions can be made to a pending request. Additions are considered a new request rather than a modification of an existing request. If the change switches a form from query to modify, and requires an approval, the appropriate approver is notified.
A
An Approver is notified of a pending request via an email containing a link to the site. When they log in, they see a table of all
pending requests, a table of the most recent past requests, and a link to all past requests.
I
Note that in selecting either the Approve or Deny option boxes and clicking save, the Approver will be marking all pertinent classes/forms in that request as approved or denied. If they want to approve part of the request, and deny part, they click the Edit button next to the request which takes them to the details page (a3, below).
The table of recent past requests contains those which the current Approver has approved or denied, but which have not yet been sent to the BIM Staff. As long as the request is in this state, it is editable, but once it is sent to BIM, the record is moved to the past entries table and is no longer modifiable.
The link to all past entries takes the user to a table of all requests which have been sent to BIM, marked as completed, or cancelled. This table looks exactly like the pending request table except it includes the date the request was marked as complete.
T
While the details page shows all parts of the request, including those not relevant to this user, they are listed showing which Approver is responsible for each part along with the current status of that part: Pending, Approved, Denied, Cancelled.
For each form/class the Approver has authority for, they can do the following: approve/deny each individual part of the request, change the nature of a form (modify or query), and change the name of a class they will approve for the request. There is also a field into which the Approver can enter comments, such as explaining a change or denial. If the Approver makes changes to the request (either the class name or the form nature), then upon saving, an email is sent to the Requestor so they can examine the change and refute as necessary.
This page can also be used to change previously set permissions. For example, if an Approver has been convinced to change a denied request to approved, and the request had been marked as complete, the request status would be changed to reopened and an email would be sent to the BIM staff asking them to add the newly approved permission.
When the Approver either approves or denies a request, and clicks the Save button, the request is removed from the list of pending requests and added to the list of recent past requests.
Once all Approvers have responded, providing at least part of the request was approved (and if/when the FERPA is approved for a new account), an email is sent to the BIM staff notifying them of a pending request. If any Approvers denied the request, an email is also sent to the Requestor and Coordinator so they can look into it.
User, FERPA notice (r1):
When a request is submitted and approved (as necessary), an email is generated and sent to the User asking them to click on a link to login and approve the FERPA notice.
If there is no response, the email is sent two more times, at intervals of one week each. If there is no response one week after the last notice is sent, an email is sent to the Coordinator for them to decide on the next action.
W
BIM (Banner ID Management):
W
Each request in the table also has two option buttons: one to deny the request (only exists when the forms/classes require approval from the BIM staff), and another to mark the request as completed. If everything is approved, the BIM staff give the user access to the desired forms/classes and marks the request as finished by selecting the “Completed” option and clicking the “Save” button. If instead, the denial option is selected, the Coordinator is notified.
The past requests table shows all requests that BIM staff have marked as completed or denied. It shows the date the request was made, the date it was completed/denied, the User’s username, firstname, lastname, and campus, the forms and classes they requested, and the final status (completed/denied). Clicking on the view button will take the BIM staff member to a details page showing all information for the request.
The BIM staff receive a daily “termination report” of people who no longer work for U.H.. In response to getting this email, they check to see if those people have Banner accounts, and if so, they send an email to the Coordinator to determine is the account should be terminated. If the account needs to be closed, the Coordinator make a new request to remove all permissions. Since no approvals are needed, the BIM staff receive the request directly and cancel the account.
ToDo: If an error is found in a completed request. Who should edit it? And how?
Feature Set:
Bold Items: These are features required for version one, these are the minimum working set.
Underlined items: Version two features.
All others are for future versions and are in order of priority.
All users:
Login/Logout
Coordinators:
Submit new account request
Submit change account request
Cancel existing request
Get notification of completion
Get notification of denial
Get notification of user or requestor cancellation
Mark request as urgent
Submit change to existing request
Copy another person’s permissions to save data entry
Users:
Send email for FERPA
Accept/Decline FERPA
Cancel request
Approvers:
Get notification of pending request
Approve/Deny request
Change approval/denial of pending/completed requests
Edit pending requests
BIM:
Get notification of pending request
See status (approvals, etc)
Mark request as completed or denied
Future feature: Search. Will need to be able to page through the results as well. The search feature should be searchable by user name and by the involved class/form (eg: who requested access to form ‘x’).
Changes:
V.2 -> V.3
1.) Changed process from Coordinator->FERPA->Approvers->BIM to Coordinator->Approvers->FERPA->BIM.
2.) Added last paragraph to BIM section describing the process for removing an account.
3.) Added ability for Approver to edit the request (change class name or access type for forms). Includes email notification to the Requestor.
4.) Added first/last name and campus to all forms.
5.) Added means of undoing past actions for a Coordinator.
6.) Replaced Edit button with View in BIM staff past requests table.
7.) Added a new role “User” which is what Requestor used to be. Requestor has been redefined as the boss of User and the person who likely asked the Coordinator to make the new account.
8.) Added means for a Coordinator to request a copy of another person’s account.
V.1-> V.2
1.) Changed the coordinator form to get rid of the checkboxes for selecting classes and replace them with fields. It’s more efficient for the users given their subject matter familiarity.
2.) Merged c2 (add to existing user) and c2a (edit existing permissions) because it seems odd to have the user add in new permissions while not being able to see what the existing ones are without going to another page. This has the side affect of allowing multiple changes (new permissions, and changes to old ones) to be submitted in one shot, which is more efficient for all involved.
3.) Deleted question regarding if one user can hold multiple roles, as the answer is "Yes."
4.) Changed handling of a Coordinator submission where no classes/forms are entered. Instead of triggering an error, a default set of permissions is assumed.
