Understanding Directory Profiles
June 8, 2015
In the old days, every faculty and staff member had several different one page directory profiles on several different websites. These pages were largely manually maintained by different people and would frequently be out of date or disagree with central university systems. Because they were manually maintained, keeping them current was an expensive process.
To improve consistency and make updates as easy as possible, we now automate all standard personnel profiles using data from central systems. While all information in a profile can be overridden at the site level, this is generally discouraged.
To ensure consistency and accuracy across the university, we use data from systems of record whenever possible.
|Source||Examples||Where to Update|
System of record for many employee facts.
|HR Self-Service Portal|
Research in View
The university's official tenure tracking system.
|Research in View Sign-In|
Canonical system charged with managing our digital identities including authentication.
A gravatar service, maintained by University Relations and Arts and Sciences.
* The url is the only field used from preferred personal information.
Many central data sources contain restricted information and it can be extremely difficult to extract data from them. Instead, we leverage a university data hub, called KMdata, which securely aggregates and serves public data from central systems.
It takes up to 24 hours for data to enter KMdata from central systems. Our sites sync information from KMdata hourly throughout the day, a few people at a time. In practice, most sites (including departments) sync all people within 8 hours. However, sites with very large directories (like the college) may take up to 48 hours.
Photos from OPIC follow a differentl update process but are ususally updated within 24 hours as well.
In HR, addresses are represented as four fields address1-4 and three of these can be updated in the self service portal. While these fields are not consistently used, often a street address (2070 Neil ave) goes in the first field and a bare room number in the third (025). There is also a building code associated with each appointment and this can only be updated by an HR representative.
Directory.osu.edu (Find People) uses the address fields to show an address but they use the building code on the appointment to show a building. As a result, it sometimes happens that the address and building will not match on directory.osu.edu. We avoid this problem by attempting to dynamically match the street address with an known address for a building, but only when the most common pattern is used (street in address1, bare room in address3).
For example, consider the address for web services.
address1: 2070 Neil Ave
In our system, this might appear as:
025 Hitchcock Hall
2070 Neil Ave
However, if HR had the old location associated with our appointments, in directory.osu.edu, it might appear with a non-matching building and address.
025 Bolz Hall
2070 Neil Ave
Within KMdata, appointments show up to 2 weeks before becoming effective, and they stop appearing as soon as they are no longer active. This means that if a faculty member is starting in fall, they won't appear in KMdata until two weeks before their official start date. In contrast, directory.osu.edu shows all future effective appointments.
Within a site, editors have the ability to add or edit content from central systems. So a site editor could add an appointment or edit the title of a journal article but they could not remove a patent. However, those changes would only exist within that site.
Site Specific Information
In addition to overrides, some information is specific to a site. This includes:
- Any rich text narratives like an "About Me" section.
- Any categorizations used by the directory (most commonly used to separate faculty/staff/students/etc).