Note, to see an enlarged version of any image, right-click on it and select the option to open it in a new tab or window.
Approvers/Functional Leads
1.) What circumstances would cause you, acting as an Approver/Functional Lead, to edit a request?
2.) Given question 1, what sort of edits do you make?
3.) Given question 1, what is the current process for making such edits? For example, do you email the Coordinator to tell them you made the change? Do you just forward it on to the Banner Id Management people?
4.) What information do you need to see in the summary table of requests pending your approval?
5.) What information do you need to see in the summary table of past handled requests?
6.) What information do you need to see in a detailed listing of a request? Currently, I'm planning on showing the User's information, the Coordinator's information, a listing of all past requests, a listing of all current permissions, the status of other Functional Leads' actions on this request, a history of all actions of this request, and the form through which you Approve/Deny the individual parts of this request. Too much information? Not enough? what else?
Coordinators
7.) A request was made for giving the ability to copy another user's permissions. Does this ever happen in the current process? For example, do you ever dig up an old email to copy the permission requested? Or do you ever tell the BIM staff "Make the permissions like so-and-so?" How often would this feature likely be used?
8.) What would be the most useful information to include in a summary table of pending requests?
9.) What information do you need to see regarding the details of a request? Right now I have: basic user information (name, contact info), date the request was made, approval status, ferpa status, comments, and the list of forms/classes requested. Anything else?
Banner Id Management (BIM)
10.) BIM staff get termination reports which cause them to immediately cancel an account. When this occurs, are there any other actions taken? Such as notifying a Coordinator, or sending email to the affected User?
11.) Given the previous question, are there any other "back-door" actions that the BIM staff make?
12.) What information do you want to see in the summary table of pending requests?
13.) What information do you want to see in the summary table of past requests?
14.) Would you ever need to edit a completed request? I don't mean editing an account, I mean a specific request. Under what circumstances would you edit it?
5 comments:
#10: We currently receive daily termination reports. We will check for any active banner accounts and send an email to the appropriate coordinator to confirm whether or not the account should be terminated. Their positive response will become the authorized request to disable or terminate the account.
#11: We do not do any "back door" activity that would alter anything. As mentioned in #10, we do verify that a banner account exist and send an email to the appropriate coordinator or functional lead whether to remove, disable, or retain the account.
#12: User information (name and username) and nature of the request (new, modify, remove, etc).
#13: User information and privileges. Also, the date of when it was marked as completed.
#14: Only reason I can see for us needing to edit a completed request is if we filled out the details erroneously and wanted to correct it.
#7, the "make his like hers" approach to requesting security when adding staff is very typical in my experience. Sometimes this can be handled by roles and sometimes not. If a role encompasses a lot of people, then they work well, but if there are many pairs and very small groups of people with similar security then copying can be more efficient to administer. At some point, supporting both approaches might be the most beneficial.
#7: It would definitely be useful to have a copy function since requestors are not likely to describe every form/role they need in Banner. A requestor will typically identify the job position s/he holds at the campus.
Speaking of the requestor, what does the request form look like? I don't think a requestor will be able to name the Banner forms, etc. Consequently I hope it is a free-form text input.
#8: I'd like to see the full name of the user. Also, I'd like to see the date of approval or denial of the request. It could either be in another column or it could be in the STATUS field itself (e.g., Approved 10/30/2007).
It's not clear to me exactly which requests I will see as a campus coordinator for STAR. Do I see all the requests made by a UHH-affiliated person whether or not it pertains to my area of responsibility? I sure hope not.
Will we be able to download the summary table as a xls file? Currently, I have to maintain a spreadsheet to keep track of all the users I've approved for STAR for Advisors. It would be great if I could just periodically download the data on a need basis.
#9: Seems pretty comprehensive enough as long as the date of approval/denial is included as well.
Miscellaneous comment: The slide presentation indicates the FERPA message will go out to the requestor as soon as the request is made. I think it
should not be sent out until the coordinator and/or functional lead has approved the request in the first place.
I think this will be a great help once the kinks are worked out.
Approvers/Functional Leads:
Regarding Question #1:
The Treasury Functional Leads will need to review/edit a request if any of the Treasury classes (CSH2, DCSH, FIS2, SCSH, SWADM, or TREAS) is being asked for and/or a direct assignment to one of the Treasury forms (Txxxxx) is being requested.
The Financial Aid Functional Lead will need to review/edit a request if any of the Financial Aid classes (FINAID_xxxxx) is being requested and/or the direct assignment of an F/A form (Rxxxxx) is being requested.
The Student Functional Lead will need to review/edit a request if the REG class is being requested.
All Functional Leads will need to review/edit any request if Developers' access (SPC or STUDENT_ITS) is being requested.
Question #2:
The types of edits a Functional Lead may make is changing the class that they will approve for the request and/or changing the nature of the directly assigned form (i.e. modify to query only) that is being requested.
Question #3:
Currently, the practice I have seen is that if the Functional Lead makes changes to the request and forwards the request on to banner-idmgmt with a cc to the requestor. If the changes does not satisfy the requestor, the requestor can rebuttal the decision.
Question #4:
Given your screen shot "Approver:Welcome (a1)", the only thing I would add is the user's first and last name and their campus affiliation.
Question #5:
The (a1) screen shot seems to cover most of the bases. Date the request was completed or the current status of the request along with a summary of the request. As with Question #4, having the user's name and campus affiliation will be helpful.
Question#6:
The screen shot (a3) reflects an appropriate amount of information. I don't know if it has been decided to redefine some definitions where "User" will be the actual person that will be using the account and "Requestor" is that person's supervisor who is making the request to the Campus Coordinator. Both "User" and "Requestor" names should then be reflected.
COORDINATORS:
Question #7:
Yes, this happens quite often where the request will ask for an account to be created with the same privileges as another existing account. It's pretty close to 50-50 that this kind of a request will be made.
Question #8:
The screen shot (c1) does well to reflect the needed information, but again, would also like to see the user's name (first and last) as well as the campus affiliation.
Question #9:
The detailed information as mentioned seems appropriate and enough. Again, if we separate the "User" from "Requestor", both should be reflected in the detail page.
Many MANY MAHALOS for your hard work on this.
Post a Comment