Directory Issues and Answers
For the definitions of acronyms and terms used below, please see the glossary.
1. How are policies and procedures to be established so they will be timely with the development of the project?
Refer to the DI&ADM for review
2. The project team must have API support ready by July 1 for the stakeholders. This should allow them sufficient time to make changes to their programs to accept data.
The committee has determined that this is not an issue.
3. What office(s) will be responsible for the directory once the project is complete? Who will own the code? Who will be responsible for the on–going training?
This organizational issue should be decided by Dr. Frazier in concert with other organizational restructuring. (This issue need not be resolved prior to the implementation of the project.)
4. What will be the policy/procedure body for the directory once this project is completed?
DI&ADM/VPIT
5. Who owns the data for an individual?
Combined effort between Directory Administrator and the DI&ADM. Depends on the attribute. Individual owns attributes such as name and address. An office will manage its attributes. OUR, for example, manages the student classification. Personnel manages the job classification.
6. How will the 8–character alphanumeric UFID be issued?
Agree with pre–populating existing students and staff with the already assigned 8 character unique Gator One ID number. From there the directory will initially generate the number for all new students, staff and affiliates.
7. How will the 9–character UUID be issued?
Yes, these should be computer generated as needed at the time of adding a person/organization to the database.
8. Who will be able to view the 9–character UUID?
Should be available to software only with selected availability based on documented need as decided by VPIT
9. Should UFID's and UUID's be generated differently for organizations and individuals?
This doesn't really matter to us just as long as these algorithms don't collide. There should be some other element in the directory that would signify person vs. organization.
10. After the new directory is implemented, who should have access to SSN's?
Decided by VPIT based on justification.
11. After the new directory is implemented, can SSN's be replicated to data structures on campus or only to distribute information to government agencies, et.al., as mandated?
SSN's should not be replicated routinely. Some entities will need the SSN and this use should be decided by VPIT based on justification.
12. When a new person/organization is to be added to the directory, the system needs to be able to tell if this entity might already exist in the directory. What data is to be used to resolve this question? Will the requested data be sufficient to add a Shands patient? Will some adds require human intervention? Who should be permitted to do this?
System should match against key fields (e.g., last name, first name, suffix, SSN, address) to identify possible duplicates. Data administrator or designee will need to make/approve the final decision. We cannot answer for Shands patients. Note: This seems that it should be listed as a separate question from whether or not an entity is a duplicate.
13. Should students applying to the university be included in the directory with this project?
Yes
14. Should patients at Shands be included in the directory with this project?
Design should allow for this however patients do not have to be entered during the initial implementation.
15. Should vendors be included in the directory with this project and donors?
Design should allow for this however vendors/donors do not have to be entered during the initial implementation.
16. Should foreign nationals making application to work at the university or to enroll in the university be included with this project?
Yes
17. Should non–credit students through the Division of Continuing Education be included with this project?
Yes
18. The central database should be updated first whenever the directory is used and then have data feed out to local directories, i.e., Registrar's Office, personnel offices, departmental directories.
Yes
19. The university needs a cultural shift from updating directory i/nformation just once a year in item for the hard copy directory to doing it on an on–going basis.
Yes
20. We need to have defined procedure of how to determine who is allowed to change data in the directory. Who is empowered to decide?
Once data elements are provided we will make a recommendation on who should be allowed to change them. However, in conjunction with the directory administrator these decisions will be made on a case–by–case basis.
21. The directory will permit the listing of an internal working title. Who should be permitted to input/update this information?
Directory coordinators in the department in which they work.
22. Directory coordinators need to be clearly aware of their responsibilities with the new directory.
Yes, training should be required for all directory coordinators. Role and responsibilities should be clearly defined in training.
23. Which offices should be permitted to change an individuals home address? Human Resources? Registrar's Office? Traffic & Parking? Others.
Implement allowing those who currently process addresses to the existing university directory. Evolve to allow other entities to update as they are approved to provide feeds to the directory. The directory administrator would manage this together with the VPIT.
24. Users need to access the directory data each time they want to use it and not download information to a shadow system.
Yes the goal is to not create or maintain shadow systems but downloads are important for some business practices. Live access is preferred for timely data.
25. How long should data be maintained in the directory for an individual or organization? What should be done with information for individuals who apply to the university, but never attend or are never employed? What should be our retention procedure?
Maintain as long as the retention schedule requires. Keep as retention schedule requires delegate to all folks to tell directory how long the directory should maintain their records, human resource, admissions, foundation, SFA, etc.
26. How will we handle updates to W–4 information when an individual's home address is changed in the directory?
Allow the change to be made. Notify personnel, the department and the employee of the need to updated W–4 information with the university.
27. Information should be fed into the system more frequently than by daily batch except as approved?
Updates should be interactive but batch updates should be accepted as frequently as they are needed. Care should be taken to make sure that batch addresses are more current than existing addresses. Directory administrator will have to receive justification for batch updated capability.
28. The Registrar's Office would like to be able to re–certify periodically that changes where made to data for an individual.
Access and compare in batch. We would like to be able to run batch comparisons.
29. The university should have one place that stores authentication and authorization information. Decide who/how we will establish the authoritative source?
Because of the new middleware approach, NERDC should maintain authentication information as well as the middleware necessary to use it. Authentication and authorization issues are beyond the scope of the Directory Services Project at this time.
30. Who is to decide how authorization to use directory API's will work?
VPIT as delegated to Directory Administrator which would be predetermined by the DI&ADM to be only central application development groups.
31. Is GatorLink ID going to be used for authentication?
Yes, the GatorLink ID should be used for authentication but pins must be supported until conversion can be implemented.
32. We will need authentication to resolve who can have access to the different API's to get information or to read data.
The Data Administrator in conjunction with the VPIT based on justification from requestor will make this decision.
33. All the direct support employees like the University Medical Center in Jacksonville need to be able to allow their employees to be able to have access to UF systems so they can use UF processes for the faculty in Jacksonville, i.e., TRIPPS.
GatorLink account and authentication from GatorLink services.
34. To be successful with this project, it would be helpful if all students were required to have a GatorLink account. Can this be a policy?
It is the policy –– just not implemented yet.
35. It would be helpful to have a policy that said that all employees and students must have an e–mail address that they will use for UF business.
Student e–mail is the GatorLink ID and that will be the only e–mail ID that will be in the directory, we also recommend that staff and faculty have a GatorLink e–mail address to which their official university e–mail will be sent.
36. UF Foundations would like to use permanent e–mail addresses for the people with whom they communicate. At what point would these addresses be protected if someone doesn't want an address given to other areas on campus or used under a public records address.
Office of the General Counsel have to discuss and decide what the policy should be.
37. We should have a way of measuring our success in maintaining quality directory information. Any suggestions?
Periodic audits or surveys sent to people in the directory asking if their information in the directory is correct. Poll departments to see if they are using it and why/why not. If they are using it because they have to, then find out whether they like using it and why/why not.
38. An individual can have many roles with the university, i.e., student, employee, patient (?), alumni, applicant (?), affiliate, donor, Athletic Association. Given this, how do we decide if the directory information for that individual must be disclosed under the public records law?
Office of the General Counsel will have to recommend options for DI&ADM to review and recommend to ITAC. Legal counsel will need to recommend resolution regarding potentially conflicting roles and regulations.
39. If someone is a Shands patient in addition to having other relationships with the university, are we restricted as to what information can be made available to different views of the directory?
Office of the General Counsel have to recommend options for DI&ADM to review and recommend to ITAC. HIPAA will protect disclosure of protected health information (PHI). Legal counsel will need to review disclosure of information for patients.
40. How do we handle FERPA, Buckley and HIPPA requirements in regards to policy and use of directory data? What do we do if a person has conflicting roles?
The Office of the General Counsel will have to recommend options for DI&ADM to review and recommend to ITAC. Legal counsel will need to recommend resolution regarding potentially conflicting roles and regulations.
41. Could the whole directory database come under HIPPA if patients were included?
The Office of the General Counsel will have to recommend options for DI&ADM to review and recommend to ITAC. No, HIPPA covers protected health information only. Legal counsel should review this issue to insure compliance.
42. An individual can have many relationships within the university. Should all these relationships be displayed for an individual? Should an office other than the individuals primary office be allowed to view fields that are marked “not published?” Should only the primary office and the individual be allowed to update directory information on–line?
Relationships should only be displayed to the entity owning that relationship unless justified to the directory administrator to need additional access. We implement with the same authentication that has already been approved for viewing these data. At the discretion of the owning department, Office of the General Counsel, or higher authority.
43. Are there roles which might be mutually exclusive, such as a person who is a half–time employee and a half–time or full–time student?
If these conditions are identified, the Directory Team will code to accommodate these types of conditions with guidance from the DI&ADM.
44. Once information is put into the directory, it needs to be available for other systems (including college/department offices) to pick up. Should we use a single queue for this or should we have multiple queues? How long should the data be kept in the queue if it is not picked up? How often should offices be required to pick up the data? How do we decide who should have access to these queues?
We should use multiple queues. The data should be kept in the queue for a maximum of a month (some fields may be updated at each pay period). Offices should be required to pick up data within two weeks, if used.
45. We will need procedures on who can query LDAP. How will information be made available to users that need the data to do their business?
VPIT as delegated to the Directory Administrator. Everyone can query LDAP. We will need procedures to determine which fields and records can be viewed using LDAP.
46. Who should be allowed access to the different API's?
API's must be further defined before this question can be answered. To begin with, units should submit their requests to be a designated member of the Directory Development Team. Post directory launch, requests should be submitted to the Chief Directory Administrator or his/her designee.
47. The project team needs clear definition on the different types of students, i.e., part–time, full–time, graduate student, undergraduate, professional. Do we need to worry about outside definitions of students, such as the national clearinghouse?
The Registrar's Office will provide a feed to indicate the full or part–time status of an undergraduate, the Graduate School will provide a feed to indicate the full or part–time status of a graduate student and the Dean of Student's Office will need to provide ad hoc input as to whether a student's standard or full time status should be amended due to a disability. The Clearinghouse data will be managed by the OUR.
48. How can we handle the sense of responsibility of users who make changes? If someone in Traffic & Parking changes an address for an employee, we need to make sure that the person who is making the change knows which address to change, i.e., local address, permanent address, etc . What if the address is date effective, such as many of the addressed used by Foundations?
The intent of the system is to provide distributed update capability to all affiliates. There may be some exceptions to that policy. Training programs will be a necessity to insure data accuracy. In addition, system displays should have intuitive formats to assure accuracy as well as user prompts to help prevent errors.
49. The directory needs to have high quality data to be successful. We need to be able to identify those areas that are not making high quality changes so we can help them in correcting their procedures. We need a procedure to deal with quality deficits.
See above and system logs will provide edits for supervisors to use in training and evaluations.
50. We need a policy/procedure defining what information from the directory can/cannot be sold.
None of the data should be sold. Legal counsel should determine whether the data must be provided under the open records law and appropriate costs recovered through the process provided by the law.
51. Will we be sharing directory information with outside sources such as Bell South, Motor Vehicles, state telephone directory, etc?
Yes, we will provide some of these entities with data upon request as we have in the past, but the Vice Provost will decide on some data sharing issues on a case–by–case basis.
52. Could Legislators and the Board of Trustees be added to the directory and given access to data?
Justification will have to be provided to the VPIT to determine if it is appropriate to add a legislator to the directory. Board of Trustees by virtue of their position would presumably be in the directory if they and the VPIT so desire. Access to this data will be provided through current standard reporting requirements to the BOE and Legislature on a case–by–case basis as approved by the VPIT.
53. Should we house student classification in the directory?
Not at this time, however if a relationship is created only the owner can see it unless authorized by the owner to be seen by other entities.
54. The project team needs to work with Planning and Facilities to identify valid places/locations on campus.
See Frank Phillips or Fred Cantrell. Such validation of locations is desirable but must not slow the overall project.
55. The new directory should provide a better way to produce labels, mailing lists and merge files.
Yes
56. Could a mechanism be set up which would allow some offices on campus, such as the Registrar's Office, IFAS, to update their records and the UF directory from the same on–line update? Could they use this mechanism to add someone to the directory?
We believe the technique for this has already been decided and support update first and foremost to the directory record. All subsequent extracts are subordinate to the original update. When adding entities to the directory, the directory and only the directory controls the creation of a UUID. It is consulted first during the unit of work of a logical transaction. Remote systems may initiate the creation of a UUID by the directory.
57. There needs to be a standardized name format. How do you list D'amosta vs. Damosta? Where is Jr. listed in a name? The team needs to develop a standard and make a proposal for its use.
A solid international standard exists for this. It's a book called Anglo–American Cataloging Rules or AACR–2 for the latest version. Libraries, of course, have faced the same problem in standardizing the form of names for authors in many languages. AACR–2 answers every conceivable question on this issue. The team should obtain a copy from the library. Software might also be available to help with this.
58. How do we map the current directory information into the new directory?
Directory Team should propose a mapping strategy to be reviewed by the Directory Steering Committee and DI&ADM.
59. The team must make available published formats on how users and stakeholders can easily get to the data and download as needed.
Yes, the sooner the better. General presentations about the data structure and capabilities would be helpful. Separate technical presentations regarding table layouts and APIs will also be needed.
60. The Library is to implement a new system during the 2002–2003 year. The team needs to work in sync with them on ID's.
Yes, it would be best if the Library could use the new UF ID to avoid students having multiple ID's and multiple issuing authorities.
61. The team needs to work with Cindy McMillen to identify the requirements that are currently needed for the hard copy campus directory. Example: how do we list names, departmental information, college information.
Yes, this seems a functional issue to define the status categories that should go in the hard copy directory. Certain group statuses (those designated in 13–17 and 52 above) would not be included in print directory. Not sure if there is also a question of name formats in this question?
62. The team needs to talk with the Library about having a system that will tie in with all the universities in SUS using similar data.
Yes, it would be best if the Library could use the new UF ID to avoid students having multiple ID's and multiple issuing authorities.
63. Would the directory provide a way to allow for single sign–on in the future to all/most systems?
Yes we recommend that there be a single sign–on for all systems and the directory should be a part of that process at some time in the future.
64. After the directory is implemented, there needs to be an office available to help users with the directory. That office will need to train departments/units on transferring information and to answer daily questions both on–line and by phone.
Yes, a central directory office needs to be created for this.
65. Ongoing training needs to include an explanation of the logic that is used when ad address or phone number is changed, i.e., an individual must have a primary address, addresses can be date effective, how to designate the office/lab with which a phone number is associated.
Yes, create rules/standards for data entry; build in system edits/checks; have an on–line manual available as well as Help screens.
66. Should we have an evaluation of this project?
Yes, the accuracy of the data in the directory should be measured on a regular basis and actions taken to improve quality as needed.
67. The Communications Team needs to work with end users to make sure definitions used in the directory are clear.
Yes, before definitions are finalized, have a sample of prospective users from various constituencies review them to see if they are clear and concise.
68. The directory will be able to list relations for an individual, i.e., son, father, cousin, aunt, mother.
Yes; question: Is this for relations who are UF members, or for emergency contacts, or unique to patient records? We should assume that any relationship to a person or group that exists in the directory can be viewed. Again, these should be secured by defined, validated, and agreed to criteria.
69. Individuals who wear multiple hats which give them relationships with more than one office on campus will be allowed a narrative box next to each phone number which can be used to list the office with which the phone number is affiliated.
Yes, but we should have a set of fixed descriptions like home, faculty office, administrative office, etc. Once those are there then it would be appropriate to have another narrative box for non–standard description. Use a simple description for each phone number.
70. We need clear procedures outlining the difference between publishing/not publishing data and protected data per public records requests, FERPA, Buckley, HIPPA.
Yes, get guidance from the General Counsel's Office and have them review the procedures.
71. The directory will support department extensions for data that some areas will want to maintain for their employees.
OK, this refers to extensions of the data model.
72. We will have data entry standards, i.e., postal standards, use of upper/lower case.
Yes, create rules/standards for data entry; build in system edits/checks; have an on–line manual available as well as Help screens.
73. Mechanisms will be in place to identify individuals whose information is to be protected under the public records law.
Yes, this must be a required field with various codes for suppression of release to public records request based on category of individual, as required by statute.
74. Show users how they can identify the person they are trying to select in the directory when several people have the same or similar name.
Yes, provide search function help. Should be part of the on–line users' manual and help screens.
75. The possibility of public record requests can cause people to give bad information for addresses and phone numbers. Individuals need to be made aware of the difference between the published/not published flags on fields and the protected flags on individuals.
Yes, employees, students, and affiliates entities need to be made aware of these issues. Identify fields that are normally open to the public. A section in the users' manual should address public records concerns and those fields where an individual can opt out, or request an exemption.
76. A person will have only one 8–digit UFID and only one 9–digit UUID. The UUID will never change. The UFID could be changed if the ID has been compromised and a change is requested.
Yes
77. If a phone number is unlisted with Bell South, is it exempt from public records law? How do we handle this in the directory?
The Office of the General Counsel can determine how this will be handled.
78. Can the UFID be reused? If so, how long should it be dormant before it can be reused?
The team recommends it never be reused.
79. How will we sort lists? Will we display numeric characters first or alpha characters?
EBCDIC sort sequence (alpha first), since it is the DB2 storage sequence.
80. When someone is added to the directory, do we need to disclose information in regards to public records requests? Should we tell them how they can request exemption from public records requests?
Same as #75. People should be told how the information will be used and how their information can be protected.
81. Who within the directory is subject to the public records requests?
The Office of the General Counsel will determine.
82. Can the UUID be reused?
No, the UUID is internal, permanent and non–revocable.
83. Will the directory provide the central authentication mechanism?
The directory will be an enabler for the central authentication mechanism. Providing central authentication is beyond the scope of this project.
84. Will emergency contacts be in the Directory? What if the contact is a police officer? Can an emergency contact be added via self–service?
Yes, the directory should be as comprehensive as possible. Existing procedures and rules must be observed. The question of what information in the directory can be changed by the user also needs to be asked. For example, users should be able to change phone numbers and addresses, but not rank nor student classification.
85. Can there be a mainframe view of the directory for quick/useful response?
Yes
86. How will be educate/train the students on the new ID's?
Education is the responsibility of the DI&ADM committee. The team would suggest using hard copy mailings as well as e–mail notices from Dr. Frazier. We could also use this as a public relations opportunity for introducing the new ID's. An article in the Digest could also be used to “get the word out.” Perhaps with a GatorLink ID and password, we could let them enter their SSN and we would tell them their UFID.
87. How will the directory be interfaced to NDS, AD, Video directories? Call managers and other proprietary directory systems?
Other directory systems can be customized to access the UF central directory via API.
88. Will the directory provide e–mail group capability? If so, who can create and maintain groups?
No, e–mail groups are beyond the scope of the directory project.
89. What is the relationship of the ERP to the directory?
The systems are complimentary. The directory is the authoritative source of information about people and organizations. The ERP will interface to the directory, as will other systems. The ERP may initiate the creation of directory entries. See #56.
