In Veracross, each person is automatically assigned a person ID when their record is created. That unique identifying number remains theirs forever. It is not changed based on role, status, or any other aspect of the system. This is at the heart of the “one person, one record” philosophy of the architecture of Veracross.
The benefit of this database-level integration is that any information associated with a person, from an initial pre-app filled out prior to second grade, to all grades and academic information, to donor records and more later in life, are all related to the same person ID. Security roles in Veracross limit access to only those people who need to see certain information, so for instance, a development officer will not be able to see a donor’s 12th grade calculus exam score from ten years earlier when she was a student, but that information does exist associated with that person record, and is accessible to those with the proper role. The guesswork inherent in non-integrated systems is eliminated (“Is this John Smith who just gave us $20,000 the same John Smith who lettered in swimming ten years ago, and was admitted to the school on scholarship ten years before that?”).
Example: A Person ID Does Not Change
Take a hypothetical person, Bob Abbott, who applies to a school. As soon as his person record is created, whether manually by an admissions officer or automatically in a pre-app, he is assigned a person ID by the system, incremented by one from the most recently created person ID. For our example, that person ID is 57623. Bob will have that person ID as an admission candidate, and then when he becomes a student, he retains that person ID number, even though he is now part of a different area of Veracross (registration and academics, instead of admissions and enrollment). Similarly, when he becomes an alumna on graduation, then later a donor, the development officers will be looking at her records, but still at the same person ID 57623. Bob comes back as a staff member at the school and he is interacting with a different area of the system, and yet is still person ID 57623.
This principle carries through any other roles Bob has at the school. Regardless of his relationship with the school (admission candidate, student, alumnus, teacher, donor, staff, volunteer, etc.), he always retains his originally assigned person ID of 57623.
It is helpful to see different kinds of information depending on a person’s relationship to the school, defined by their role. Person detail screens in Axiom look different depending on a person’s role. So for instance, a person’s detail screen when a student highlights demographic information, homeroom teacher and advisor, locker #, etc., whereas that same person’s detail screen, when an admission candidate, highlights year applying for, inquiry/visit date, and application status. The person ID does not change.
The following URLs are examples of a person who is currently a staff member, but was once an admission candidate and then student. Note the highlighted elements of the URLs: admission-candidate, student-us, and staff, showing the different types of detail screens, but all with the same student ID (57623).
Bob as an Admission Candidate
Note that relevant information for an admission candidate is featured prominently on the General tab, and that admissions-related tabs are present: Checklist, Notes, Interview, etc.
Bob as a Student
Note that relevant information for student is featured prominently on the General tab, and that student-related tabs are present: Attendance, Schedule, Grades, etc.
Bob as a Staff Member
Note that relevant information for staff member is featured prominently on the General tab, and that general person-related tabs are present: Addresses, Related People, Employment, etc.