Campus Identity hosts data from various sources to provide one account for members of UCSB. A robust data integration of user data providing campus services with a unified view of them.
Sources of Account Data
Identity accounts are created from different data sources and consist of an affiliation to enable UCSB netid activation. The source of data for UCSB Identity accounts comes from four sources: Payroll, Registrar, Departments, and End Users.
Payroll is the source for the pre-hire and employee affiliation. Completing a record for a new employee in UCPath will create an account for them to be activated in campus identity. The account may first carry the affiliation of pre-hire depending on the start date of a new hire, but after the start date the affiliation will change to employee.
The Registar is the source for the applicant, student and umail affiliation. Applicant records are added to campus identity for subsequent quarters. When a student signs a Statement of Intent to Register, a student affiliation is added to the record and the student can activate their netid. A umail affiliation is added at the time of graduation for 13 months to continue to allow access to email. (Older student accounts may have received a umail affiliation upon activation but it acts in the same way).
UCSB Departments are the source for several affiliations that fall outside the realm of faculty, staff & students. A Department Directory Editor can use the Identity Manager to create accounts manually for people they sponsor in their department. Academic affiliate and contractor affiliations provide the same access, but are differentiated for tracking purposes. The Professional and Continuing Education department is the source for the extension affiliation adding students manually in bulk using the Identity Manager.
Multiple Account Affiliations
Over the lifecycle of a UCSB netid account there can be multiple affiliations at any given time, but there must be at least one affiliation for the account to remain active.
Each affiliation will have an end date determined and managed by the source of the affiliation. Departments control the hiring and termination of employees and control the end date of the employee affiliation. The student affiliation end date is rolled forward for subsequent quarters by the Registrar until the last quarter and graduation. The umail affiliation will remain 13 months after graduation, or a student leaving the university, for continued email use purposes. Extension students as well have an affiliation end date determined by their class length.
Departments also control the end dates of their affiliates. Academic affiliates and contractors affiliation term is one year and can be renewed by the department before it has ended. It's important to understand the flexibility that affiliates afford departments regarding their staff and associated students. For example, if an employee or student is about to be terminated from payroll or graduate, they can be made an affiliate as well, thus ensuring there is no lapse in their netid account. If a returning faculty member needs access to campus services before their payroll record is completed, they can be added as an academic affiliate to reactivate their netid.
One Netid
Once activated, a person has a netid allocated to them for life. If they leave and return, an affiliation is merely added to their existing account and their netid is reactivated. With the amount of data integration involved, an issue with new affiliations not syncing properly can occur. We monitor for data exceptions and manually merge records with existing accounts, but not all are caught. New affiliations from any source have the ability to create a new record to be activated, when it should have been merged with an existing account. It's important to contact us through the help desk if someone is expecting a certain affiliation for their account and it doesn't appear. If a person is known to have a netid, they should not activate a new one.
Identification Numbers
All primary affiliations have a unique identification number. This provides a foreign key to the source data and provides values to sync accounts with. The identification numbers are also given to users to activate their UCSB netid. Staff have an employee ID number, students a perm number, extension students an extension ID, and affiliates an annex code.
Ancillary to the unique ID numbers from source data, identity accounts have their own unique identification number called a ucsbCampusID. It is represented by a UUID number set at creation. When services require a persistent account identifier, the ucsbCampusID is sent as the foreign key.
User Supplied Data
A UCSB netid also contains an account profile where members can add information like preferred first name, address, email address, and telephone number. Department Directory Editors can also edit account profiles to adhere to department policies on white page information. Along with source data, user supplied data rounds out the data set of an individual account. Because this data is shared with other campus services, it is important to keep the account profile up to date via the Identity Manager. A default email address should always be present for members to receive official UCSB communication.
When a UCSB netid is activated, a corresponding email address is created in Google Workspace for Education. UCSB provides its members with a suite of useful collaboration tools from google, like Gmail and Calendar. The syntax of a gmail account is netid@ucsb.edu. Departments may create email aliases for the gmail account to accommodate their email address policies. Umail is also an alias to help coordinate communication to the student body. However, to avoid confusion when third parties and services require an email address as an account identifier, the default syntax of netid@ucsb.edu is sent by campus identity.
Data Provisioning
Since identity accounts are created from other sources, there is no unique identifier to sync on. Merge logic is run on each new affiliation to determine if the person exists and already has an account. The merge logic will compare other common person data, like date of birth and name. Identity provisioning errs on the side of caution and does not merge a new record with an existing record unless it is sure it is the same person. Exceptions to the automatic merging of data that occur are logged, reviewed, and merged manually on a daily basis.
The largest group of merged records are student employees. To decrease the overhead of evaluating account data for the large number of exceptions, an update to UCPath has been approved whereby it will offer a field for student perm number. When students apply for a job at UCSB, it must be required that they supply their perm number. This will allow their new employee affiliation to sync with their existing student account easily and without interfering with merge logic.