Username Conventions & Account Redirecting

As of July 12, 2021, this "Learn Veracross" site has been deprecated.  It will remain live through December 2022, but will no longer be updated. All knowledge content has moved to the new Veracross Community.  Please update your bookmarks.

Here is the new version of this article in the Veracross Community.

Overview

User Account naming conventions can be set per security role.  Using the “Security Roles” link on the System homepage, all security roles can be accessed and a primary and secondary username convention set for each.

The primary username convention will be the default convention for user accounts created with each security role. The secondary username convention is used if the primary username convention produces a username that is already in use.  If the secondary username convention is not set, or if the username isn’t unique for either primary or secondary username convention, then Veracross will simply append a number to the end of the username (2, 3, 4…).

The one exception the system has to using a secondary username convention is when the primary username convention is either Email or Person ID. In either of these cases, the system assumes that those values should be unique and any secondary username convention will be ignored. If email isn’t actually unique, an error message will be encountered.

Additional punctuation or characters are allowed. For instance, if Student username convention is “{first_initial}.{last_name}.s”, with the period between those conventions and “.s” appended at the end (perhaps “s” represents that this is a Student user account), then John Smith can expect to have a username of “j.smith.s” (unless of course that username is already taken, then the secondary username convention, or appended number rules apply.)

There are several field options that can be utilized to set each role’s naming convention. This is an exhaustive list as of August 2018:

  • {person_id} Uses Veracross Person ID
  • {first_initial} First letter of First Name (will use Preferred Name if it exists)
  • {first_two_initials} First two letters of First Name (will use Preferred Name if it exists)
  • {first_three_initials} First three letters of First Name (will use Preferred Name if it exists)
  • {first_name} First Name (will use Preferred Name if it exists)
  • {real_first_initial} First letter of First Name (will use First Name always)
  • {real_first_two_initials} First two letters of First Name (will use First Name always)
  • {real_first_three_initials} First three letters of First Name (will use First Name always)
  • {real_first_name} Real First Name (will use First Name always)
  • {middle_initial} Middle Initial
  • {middle_name} Middle Name
  • {last_name} Last Name
  • {last_initial} First letter of Last Name
  • {last_two_initials} First two letters of  Last Name
  • {first_three_of_last} First three letters of Last Name
  • {first_four_of_first} First four letters of First Name
  • {first_four_of_last} First four letters of Last Name
  • {first_five_of_last} First five letters of Last Name
  • {first_six_of_last} First six letters of Last Name
  • {last_7_initials} First seven letters of Last Name
  • {last_ten_alpha} First ten letters of Last Name, alphabetic characters only (hyphens or other characters will be skipped)
  • {email} Email Address. Uses only email_1 and can be risky if the email address in email_1 may already be in use by another user
  • {graduation_year} Graduation Year (last two digits in year)
  • {graduation_year_full} Graduation Year (four digits)
  • {staff_start_year} Staff Start Year, as derived from hire date
  • {school_year} Uses the current school year value as of the time the username is generated
  • {legacy_student_id} Uses the Legacy Student ID field, which is accessible and can be updated, not to be confused with the Legacy Person ID field, which cannot be updated

In addition to the username convention, each security role has the option for enabling Password Syncing.  This is to be used only for security roles that are integrated with Active-Directory, LDAP, etc. If selected, password changing (and therefore the “Forgot Password” option) will be disabled.

If an additional field is needed, please contact your Veracross Account Manager.  Please note that only System Administrators can set a security role’s username convention.

Note: Any naming convention involving first name will use the preferred name if it exists, unless otherwise noted.

Account Redirecting

In addition to controlling how account usernames are created, there are settings that control where a user account directs after Account Setup and the Forgot Password process. The following fields are used to control redirect behavior:

  • Primary App: This field controls which application the user will be directed to. For example, the Faculty security roles would typically direct to Portals, and Staff security roles to Axiom.
  • Custom URL: In some cases, it may be desirable to direct a user to a non-Veracross app after the user sets up their account or changes their password. A school’s website is the most typical place to direct parents, if not the Veracross portals.

Precedence

Since users often have multiple security roles, this field makes it possible to indicate a hierarchy of security roles. This hierarchy applies to both the primary app settings as well as which welcome email template is sent to the user.

Example: A user with both Staff and Faculty security roles can be directed to Axiom instead of the Portals (based on primary app) because often, “Staff_1” (or other Staff related security roles) should have a Higher precedence than Faculty_1.

This also applies to welcome emails: If a user has both Parent and Staff security roles, then schools will typically want that user to receive a Staff welcome email template rather than a Parent welcome email template, because that corresponds far more closely to the actual access and work they will be doing in Veracross. In short, a higher precedence value means Veracross chooses that path before a lower Precedence. One potential benefit is that schools can have as many welcome emails as they have security roles.

Note: Lower numbers are higher in precedence, which is similar to how sort keys operate in Veracross. If precedence is configured as Parent = 25 and Staff = 10, that person will receive the Staff welcome email, directed to the Staff primary app (typically set as Axiom), not the Parent welcome email.