Disclaimer

Written by the North Dakota University System, September, 2006. Updated August 2007;

Updated April 2008; Updated November 2008; Updated May 2011; Updated September 2011; Updated December 2011; Updated April 2012; Updated June 2015; Updated March 2017

This training manual is considered to be proprietary and confidential and may not be reproduced for any reason other than stated below without prior written consent of the North Dakota University System.

This manual is the policy for creation and maintenance of Name, Address, and ID information for students, faculty, and other individuals within the North Dakota Core Technology Systems Computer Network.

Exclusion

This training manual has been prepared exclusively for End-User Training. Information contained within this document may be used by NDUS campuses for the sole purpose of personnel training. Additional manuals may be reproduced and edited as needed for training purposes ONLY. All other uses are prohibited without prior written consent from the North Dakota University System.

Copyright  2006 North Dakota University System. All Rights Reserved.

TABLE OF CONTENTS

History and Chronology of Project

History

Chronology

Common Elements

Description of Database

General

Bio-Demo Element Creation and Maintenance Personnel

Process for Finding Existing Records in CS

Process for Finding Existing Records in HRMS

Name Creation

Name Creation Philosophy

Name Types and Description

Rules for Name Creation

Process for Name Creation in CS

Address Creation

Address Types and Description

Address Element Definitions

Rules for Address Creation

Name Maintenance

Name Change Philosophy

Individuals with Current Record

Individuals without Current Status or Activity

Minor Name Variations

Major Name Changes - Description

Monitoring Name Changes

Address Maintenance

Address Change Philosophy

Rules for Address Maintenance

Address Usage Table

National ID Maintenance

Common Bio/Demo elements

Marital Status

Gender

Date of Birth

Military Status

Campus ID

Visa/Permit Data

Citizenship

Phone

Phone Types and Description

E-Mail Address

Race/Ethnicity

Disabled Veteran

VA Benefit

Relationships – examples include

Privacy Release Indicator

Campus Solutions Reporting and Security Roles

Available Bio Demo Reports

Security Roles

NORTH DAKOTA UNIVERSITY SYSTEM

NAME CHANGE REQUEST FORM

ConnectNDBio-Demo—NDUS May 2016

1

History and Chronology of Project

History

A Common NAID Number for all students in the 11 NDUS was recommended to the Chancellor by the HECN in 1994. The NDUS Chancellor’s Cabinet recommended that a committee be formed to evaluate the proposal.

The committee met twice and the proposal for the Common NAID Number was approved on May 14, 1994. The Council of College Faculties reviewed and approved the proposal shortly thereafter.

The Common NAID numbering system was converted to the PeopleSoft EMPLID System in March of 2003. The legacy Common NAID number is used to maintain a link between the legacy and PeopleSoft Systems.

A Bio-Demo Complexities Committee was established in 2008 to review many of the complexity issues arising from the use of two separate databases to store employee and student data. The need for one authoritative “source of truth” for this data resulted in recommendations for record maintenance and the need to move to bio-demo synching between the two databases.

The recommendations from the Complexities discussions along with a “sync” process moving data from one database to another were implemented on December 17, 2015.

Chronology

1994 / Proposal for Common NAID Number submitted to North Dakota University System by HECN.
May 14, 1994 / Project approved.
May, 1996 / UND NAID Subcommittee formed to develop process for conversion clean up.
July, 1997 / Employee hired part-time in UND Admissions and Records Office to begin clean-up process in preparation for merging on July 1, 1998.
October, 1997 / On-line clean-up of all institution records begins.
November, 1997 / Training meetings conducted (Fargo, Bismarck). Draft of NDUS Common NAID Handbook distributed.
April-May, 1998 / Cleanup of “duplicated” data completed at UND in conjunction with each NDUS campus.
July 1998 / Conversion to Common NAID Number System (invisible to the user).
March, 2003 / Conversion to PeopleSoft EMPLID Numbering System. Data cleanup continued in the PeopleSoft system.
December 21, 2009 / Personal Data (Bio-Demo) Integration Final Report.
March 4, 2012 / NDUS HR/FIN split from State Government HR/FIN.
December 17, 2015 / Bio-Demo synch process between NDUS HRMS database and NDUS Campus Solutions (CS) database implemented.

Common Elements

Beginning in July, 1998, the Name and Address files for individuals were merged (using the most recent data for the individual). Since that time, each institution accessed the shared or common file with the NAID unique to the student at that institution. In other words, one individual had several NAID numbers, but only one Name/Address record (file).

As of March, 2003 all Bio/Demo files for individuals within the North Dakota University System and the North Dakota State Government HR System were merged into one PeopleSoft file called EMPLID. These files are linked to the legacy Common NAID number to provide continuity. The link to the legacy system was removed when the final five campuses migrated to PeopleSoft in the summer of 2005.

Description of Database

This handbook describes the policy and procedure for the creation and maintenance of all INDIVIDUAL RECORDS OR FILES within the PeopleSoft database. The NDUS database was converted to PeopleSoft in March, 2003. Originally this database was merged from individual institutions databases on July 1, 1998. Extensive clean-up occurred before the 1998 merger and prior to the 2003 conversion to PeopleSoft. Duplicate record cleanup continues with legacy records as well as EMPLID records created in Campus Solutions and HRMS.

  • Students – Enrolled

Any individual who had enrolled at (at least) one NDUS institution since 1983

  • Students- Prospective

Any record on the legacy system with a Common NAID for a student who may or may not have been admitted but who never attended

  • Faculty

Any individual faculty member who was employed in March, 2003 at one or more of the ConnectND pilot institutions. For the remaining nine institutions, current faculty records were converted as of the end of February, 2004. If a new faculty member did not attend an NDUS institution, their EMPLID is created on the HRMS database and moved to the CS database through the Bio-Demo sync process.

  • Employees

Any individual employed at one or more of the ConnectND pilot institutions in March, 2003. (For the remaining nine institutions, current non-teaching employee records were converted as of the end of February, 2004. If a new employee did not attend an NDUS institution, their EMPLID is created on the HRMS database and moved to the CS database through the Bio-Demo sync process.

General

Bio-Demo Element Creation and Maintenance Personnel

The NDUS will designate at each institution a limited number of offices and personnel positions within those offices with the ability and security clearance to CREATE AN INDIVIDUAL on the NDUS system. A larger, but still limited group of personnel will have ability and security clearance to update Bio-Demo information.

Personnel do not create and maintain institutional data. The data is created and shared system-wide. This requires careful controls on each campus to ensure records remain clear, accurate, and unduplicated.

Primary responsibility for records maintenance on each campus shall be within the following offices:

Student Records - Admissions/Registrar’s Office (Student or Academic Affairs).

Employee Records - Payroll/Personnel (Human Resources) If a student employee, a record with EMPLID will already exist.

Process for Finding Existing Records in CS

  1. If a person exists on the CS System, their information is accessed utilizing search match capabilities. Various combinations for search match may be used. The combinations include:
  2. First name, Last name, Date of Birth, National ID
  3. Last name, Date of Birth, National ID
  4. Date of Birth, National ID
  5. First Name, Last Name, National ID
  6. Last Name, National ID
  7. National ID
  8. First Name, Last Name, Date of Birth
  9. Last Name, Date of Birth
  10. First Name, Last Name, City
  11. Last Name, City
  12. First Name, Last Name
  1. If the match does not exist in the system, the message “FUNNEL SEARCH FOUND NO MATCHES”.If this message is displayed, check to determine if the information was entered correctly and search with other demographic information.
  2. Every effort should be made to use only complete legal names in CS. Therefore, if the name provided is Bob, please search with Robert also. Other examples include, but are not limited to: Dick – or Rick or Richard, Bill – or Will or William, Liz – or Beth or Elizabeth.
  3. On National ID – do not use dashes within number. For example: 111-22-3333 should be entered as 111223333.

Process for Finding Existing Records in HRMS

  1. To verify whether or not a new hire already has an EmplID, go to Workforce Administration>Personal Information>ND Hire.
  2. The employee’s last name, National ID (Social Security Number), and birth date must be entered on the search page.
  3. Hyphens may be used when entering the National ID but they are not required.
  4. ND Hire begins with a search on SSN. If the SSN entered returns a match from either the CS or HR system, then the chance of it being an incorrect match is minimal.
  5. ND Hire then searches the individuals name and birthdate. The system searches for a similar last name and exact birth date in both CS and HR. If either piece of information does not match, the search will not return a value. In other words, if either database contains an error, the search will not be successful.
  6. ND Hire does increase the chance for a successful match by searching for similar last names or similar parts of last names. For example, if Anderson is entered, the search may return Anderson-Smith, Smith-Anderson or Anderson. Similarly, a search for “son” will return names such as Anderson, Gunderson, Sonmor, Sonderlan, etc. Searching for part of a last name can be used to anticipate different spellings: for example, if Anderson returned no matches, a search for Anders may return the name Andersen.
  7. ND Hire was written using the AND function for birthdate and name. This limits the possibility of returning numerous pages of matches. However, the AND function does apply to all the information entered in the search. Thus, the more items entered in the initial search, the lower the chance a match will be found, but if the initial search returns multiple matches, adding more items to the search will narrow the results, increasing the chances for a correct match. (Entering part of a last name will have more chance of returning a short list of possible matches if part of the first name is also entered.)
  8. The ND Hire search will return as many matches and near-matches as possible and will indicate whether the record was found in the CS (student) system or the HR system. It will also indicate the Empl Record number and whether or not the employee is in the system as a future hire, active, or terminated as of that time. It also displays the Business Unit.
  9. If the same person displays with two different EmplIDs, file a help desk ticket so the HR team to determine the correct one to use.

B.If the search is unsuccessful and the system displays the following message: “No Employee records were found that matched your search criteria”, click on the Continue icon.

C.If a matching record is found only in the Campus Solutions (SA system), select the student’s EmplID by placing a check mark in the box in the select column on the right side of the page, click Continue. This action will prevent the creation of a second EmplID.

  1. After selecting the SA EmplID and clicking continue, there will be a slight delay while the data is returned from Campus Solutions. If the following message is received, “BioDemo data transfer from Campus Solutions not completed”, click OK to return to the ND Hire search page and click Continue again.
  2. Modify a Person will populate with the data from Campus Solutions.
  3. New effective dated rows can be entered to update the employee’s current data.
  1. If a matching record is found in the HR system for your business unit, return to Workforce Administration>Job Information>Job Data. Do NOT click on the Continue button; exit the ND Hire page. Enter the EmplID in Job Data to find an existing value.

1. While in Job Data, note the existing Empl Record number(s) and Benefit Record number(s) of the person and whether each record is Regular or Temporary.

  1. If the record is Terminated, enter a new effective dated row and follow the business process for a Rehire.
  2. If the record is Active, follow the business process for Add a Concurrent Job.
  1. If matching records were found in the HR system, but not for your business unit, follow the business process for Add Employment Instance. Do NOT click on the Continue button; exit the ND Hire page.
  2. If no records were found that matched the search criteria, click Continue to proceed with the hiring. The system will assign the individual an EmplID when all the required data is saved.

Name Creation

Name Creation Philosophy

Every effort shall be made to create an individual with a COMPLETE LEGAL NAME, a SOCIAL SECURITY NUMBER, and a BIRTH DATE. A person’s record will not be created without a valid birthdate for the individual. The social security number and the birth date will be required from all individuals to the extent legally permissible.

Generally speaking, a complete and signed uniform NDUS Admission Application Form (Electronic or hardcopy) shall be considered a primary document for creating a student record.

Generally speaking, a Personal Data Form, completed and signed, shall be considered a primary document for creating an employee record. All new employees will be required to provide a copy of their social security card. The name on the card shall be considered the complete legal name for creating a new record. If a recent name change has occurred, a copy of the appropriate legal document should be attached to the copy of the updated social security card.

Name Types and Description

The PeopleSoft System allows for the creation and maintenance of multiple name types. They include:

Name Type / Description
Father/PG2 / Name of father or male legal guardian/ Parent or Legal Guardian if more than one name is needed. Previously used Father name converted to Parent/Guardian 2
Former / Former Name
Maiden / Birth name of anyone whose legal name is different
Mother/PG1 / Name of mother or female legal guardian/Parent or Legal Guardian. Previously used Mother name converted to Parent/Guardian 1
Preferred / Name by which student/faculty/staff prefers to be addressed
Primary / Legal name of individual. This is required for creation of an EMPLID.

Rules for Name Creation

  1. Use the complete first/middle names as provided.
  2. Use middle name when provided, middle initial if provided, Junior/Senior or II if indicated to create the most complete record possible.
  3. No periods, spaces or accent marks are used in names except:
  1. St Clair, John
  2. O’Keefe, John
  3. Hetland-Morrison, Judith
  1. Use spaces on name as indicated on and individual’s social security card. If proper spacing is not known, do not include spaces in name.
  1. Vanness, John (this name is John Van Ness)
  2. McArthur, John
  3. MacArthur, John
  1. NO titles such as REV, DR, FR, SR, etc., are permitted in the name fields. There is a separate TITLE field available in the system.
  2. Periods will not be used with initials.

Process for Name Creation in CS

  1. Every effort should be made to use only complete legal names in CS.
  2. Nicknames should not be used. Examples of nickname, currently in the system include Butch, Chip, Skip and/or Bud etc. If a Bio/Demo Record is currently in use with a nickname such as the ones previously mentioned, please obtain documentation of the complete legal name, update the person’s legal name field with the full name and enter the nickname in the preferred name field.
  3. The prefix should not be considered part of the name. Titles such as Dr., Miss, Mr., Mrs., Ms, Rev., are not part of name and should be excluded from the name field.
  4. The Suffix should not be considered part of the name. Suffixes such as Jr. III, etc. are not part of the name and should be excluded from the name field.

Address Creation

Address Types and Description

The PeopleSoft System allows for the creation and maintenance of multiple address types. They include:

ADDRESS TYPE / DEFINITION
Campus / Used by employees to identify campus address where the individual is employed.
Dormitory / Student’s current residence hall or campus housing address. This is added to CS nightly with information from the Housing software (Adirondack).
Home / Street address at which the individual resides.
Mailing / Postal address to which correspondence should be sent.
Permanent / Address for permanent records, usually the hometown. For International Students this is their home country address.
Other / WHAT IS THIS USED FOR?
Billing / Address for billing purposes.
Parent/PG1 / Parent/Guardian address. Previously used Parent address was converted to PG1 if a Mother’s name was available
Parent/PG2 / Parent/Guardian address if more than one address is needed. Previously used Parent address was converted to PG2 if a Father’s name was present.

Every effort shall be made to create an individual’s record with at least one of the above-listed addresses.

Address Element Definitions

The address consists of the following: