Attributes Document (SBL Data Dictionary)

Owned by Emily Bivona (Deactivated)
Last updated: Apr 08, 2024 by Jennifer Dewey
36 min read


Data Record Layout


* Required Attributes – required attributes for each section are only required when data is being sent for that section of data. For example, if there are no
"Addition User Defined Test Scores" to pass, the "Type" is not mandatory.

Completed Units is the sum of Registered and Transferred Units when the Completed/Transfer flag is true for the period.

Sending data updates

To update one data element within one of the "SBL Type" sections, all of the data elements within that section, that have data for the student, must be sent.  For example, if you needed to update a student's Address Type, and only the Address Line 1 had changed, but not the City, State and Zip, you would still need to send over all four data elements in the SBL.  If you did not follow this procedure, the data elements of that type that are sent in the SBL file would be updated with the data sent, the others would be updated to "blank."  So in this case, you would need to send us Address Line 1, City, State and Zip. If there had been no updates at all to the student's address, then the "Address Type" section could be left out of a subsequent SBL, and there would be no change to the address data fields in Regent Award. The only exception to this rule is that the "Student Type" node must ALWAYS be supplied.

Technical Guide

Validation Checks at the Schema Level

The SBL can fail based on two validations, which result in an error. The SBL will error due to a fail at the schema level or the student level (see below). If the SBL fails based on schema, there is an error in the XML format. Therefore, the entire SBL file would error out and none of the data will update into Regent Award.

Validation Checks at the Student Level

If the SBL errors due to data, that means that the student affected will not load into Regent Award. The error will only occur for one student record. Therefore, all other students that do not have issues with data will load into Regent Award as expected. If any of these validation checks fail, the data for that student is not processed. These checks are not case sensitive.
<student> section validation

  • externalStudentId1: Value must be unique in Regent Award across the entire Enterprise.

Summary of the points about the unique externalStudentId1 requirement in Regent Award:

  • Regent Award needs to track distinct student accounts for linking to ISIR's; a student in Regent Award can only belong to one Institution/Campus/Site at a time
    • Even though this may be the same physical person, for compliance reasons the ISIR cannot be linked to a student at a different Institution
  • If we allowed the externalId1 to be repeated for these different student accounts there would be no way to distinctly match the student
    • For example the SSN, Id's, DOB, name would all be same for the student and we could never get a distinct match to tell which student the data should be matched to
    • Keep in mind the Campus in the SBL cannot be used for this since it can change and since it is not in CSV imports
  • The CSV imports need a non-PII way to identify a unique student
  • The "Block" lists need a way to identify and block a unique student
  • externalCampusId: Value must match an existing External Campus ID, as configured on Campus Setup, in the system.
    • If a new campus is sent on the SBL, a new Program (externalProgramId) must also be sent in the <academicInformation> element.
  • externalSiteId: Within the set of Sites for the matched Campus in the system, the value must match an existing External Site ID, as configured on Site Setup, in the system.
  • If the student exists, the match to the student must be distinct (a distinct match is defined as a match to only one student in the system).
    • Distinct Student match:
      • When there is no match to an existing student, then the student is created.
      • A distinct match to a student is attempted in this order:
        1. externalStudentId1
        2. externalStudentId2
        3. externalStudentId3
        4. externalStudentId4
        5. SSN

When a distinct match is found the subsequent checks for a match are skipped; if a distinct match cannot be resolved the data for that student is not processed.

  • When a students' campus changes, a program change must also be sent
  • Courses cannot be specified until an active program is defined (ether in that same SBL or previously set in Regent Award by another SBL load)


<demographic> section validation

  • externalHousingStatusId: Value must match an existing External Housing Status ID in the system. (A future setup item)

<academicInformation> section validation

  • externalProgramId: Within the set of Programs for the matched Campus in the system, the value must match an existing External Program ID, as configured on Program Setup, within the system.

<sap> section validation

  • If the sap record exists, the match must be distinct. All of the following data fields must match, in order for a match to be distinct:
    • studentId
    • sapDate
    • sapReviewPeriodEndDate
    • sapReviewPeriodFrequencyCode


When no match is made, a new StudentSAP record is created.
<additionalinformation> section validation

  • name: The value must match within the set of User Defined Fields for the matched Institution (inferred from the matched Campus) in the system. Note that User Defined Fields are configured on Institution setup in the system, and are available to all campuses within that Institution.


<parentspouse> section validation

  • plusBorrower: Only one entry per student can have this flag specified as true.


<courseData> section validation
The validation of SBL course data ensures that the provided term and program are associated to the same campus as the student.

  • If the course record exists, the match must be distinct (a distinct match is defined as a match to only one course on the student's record).
    • Course data is matched on either the externalCourseID OR (if no match can be found based on the externalCourseID) a combination of the courseId/program/courseStartDate/courseEndDate.
  • externalSiteId: Within the set of Sites for the matched Campus in the system, the value must match an existing External Site ID, as configured on Site Setup in the system.
  • externalProgramId: Within the set of Programs for the matched Campus in the system, the value must match an existing External Program ID, as configured on Program Setup in the system.
  • externalTermId: Within the set of Terms for the matched Campus in the system, the value must match an existing External Term ID, as configured on Term Setup in the system. The term must also be associated with the specified program.
  • If the matched program is nonterm, the externalTermId cannot be specified.
  • If the matched program is term or nonstandard term, the externalTermId must be specified.
    • There is a validation check that determines if the program provided is nonterm or term/nonstandard term. If the 'externalTermId' was not provided and the program is term-based, or the 'externalTermId' was provided and the program is nonterm, the data will not be processed. 
  •  Courses can be linked to a closed Course Enrollment. However, special care should be taken to avoid altering past course enrollments for nonterm courses. If a nonterm course is sent with an end date in a closed enrollment, the system will reallocate the courses. The changes will alter the underlying course enrollment records and may result in changes to the Academic Plan and potentially affecting awards. 
  • If courses are provided for a student, the <academicInformation> element must be provided with an externalProgramId.
  • The course withdrawal date cannot be after the end date of the course, or after the current date (today's date).
  • The course start date cannot be after the end date.
  • The course last attended date cannot be before the start date.
  • The course last attended date cannot be after the end date.
  • The course last attended date cannot be a future date.
  • For term programs, courses cannot be longer than 24 weeks.


Handling of Transfer Units

Internal Transfers

  • SBL: <courseData> transfer="Internal"
  • Used for courses at the same school where the student has changed programs
  • These transfers should only be supplied at the start of a new program (initial program for onboarding)
    • Internal transfer units are applied to the academic plan at the beginning of the program and are at the program level only. 
  • Units from these courses are summed up and applied to the first course enrollment for the active program
  • When submitting an Internal Transfer course for a Term-Based program, the externalTermId is required.
  • The 'first course enrollment for the active program' is defined as:
    • Term-based programs
      • The earliest term for the active program where non-Internal transfer courses exist
    • NonTerm-based programs
      • The first course enrollment for the active program
      • This may not always be CE 1 PP 1. Where the prior program had closed course enrollments the new active programs CE's will start at the next CE/PP.
        • Example:
          • Program 1 – CE 1.1 and 1.2 are closed
          • Student changes to Program 2
          • Program 2 CE start at 2.1
  • When using the "Exclude Internal Transfer Courses with 0 Quality Points Towards Progression" option on Institution Setup,
    • If set to "true" (checked from the UI), internal transfer courses will count towards the progression units totals only when Quality Points are greater than zero. Internal Transfers with zero quality points will count towards attempted unit totals but not progression unit totals.
    • If set to "false" (unchecked from the UI), all internal transfer courses will count towards the progression units totals regardless of the Quality Points value on the course.


External Transfers 

  • SBL: <courseData> transfer="External"
  • Used for courses taken at another school that apply to the student's active program.
  • Course end date should align with the period the course is completed in.  If the course's units will count toward grade-level progression starting with the first period in the program, the course end date must be on or before the program start date.
  • External transfers can also be specified at any time during the program, because the student may be taking a course at another school concurrently.
    • External transfer units may be sent before the first period in the program. The course end date must be on or before the program start date to apply those External transfer units to awards in the first payment period.
    • External transfer units for courses ending after the program start date will apply to a specific term or Payment Period because they are related to a specific point-in-time. These units typically come from a different Institution.
      • Units from these External Transfer courses are applied to the specified term (external Term ID) for term and nonstandard term, or to the payment period containing the course end date for nonterm.
      • Any grade-level increases, if applicable, will occur in the following enrollment period (the next term for term and nonstandard term, or the next Academic Year for nonterm).
  • When submitting an External Transfer course for a term or nonstandard term program, the external Term ID (externalTermId) is required.
  • The transferred units only apply when:
    • Transfer="External"
    • programApplicable="true"
    • countTowardProgression = "true"
    • qualityPoints > 0  OR  Institution setup "Exclude Internal Transfers With 0 Quality Points From Progression" = "false"
  • Units are applied differently based on the course end date, the program start date, and the program type.
    • If the course ends on or before the program start date, the external transfer units are counted starting with the first enrollment period in the program (i.e., from before the program started).
    • If the course ends after the program start date, the external transfer units are counted depending on the program type.
      • Term and nonstandard term programs
        • Apply to the term specified by the external term ID.
      • Nonterm programs
        • Apply to the open course enrollment as defined by the endDate of that transferred course
  • All other flags & values on the <courseData> element are ignored and are only for reference for External Transfer courses.

Counting Instructional Weeks – Nonterm Specific

Instructional weeks are used to hard close a payment period. Hard closing payment periods allow the student to be disbursed aid in the payment period.

  • Current Course (course start date is in the past, but course end date is in the future):
    • SBL flags: attendance = true but no lastAttendedDate is sent.
    • The Attended/Completed/Progression Instructional weeks are not counted.
    • The Registration based weeks will still count.
  • Current Course:
    • SBL flags: attendance = true AND lastAttendedDate is sent.
    • The Attended/Completed/Progression Instructional weeks are counted. Regent Award counts the weeks from the course start date to the lastAttendedDate.
  • Complete Course (complete = true and qualityPoints > 0):
    • SBL flags: no lastAttendedDate is sent.
    • The lastAttendedDate and attendance flagged are both assumed.
      • The lastAttendedDate is set to the SIS provided sblCreatedDate if the course is current but sent as a complete course. If the course is not current, the lastAttendedDate is set to the course end date.
    • The Instructional weeks count from the course start date to the assumed lastAttendedDate.
  • Complete Course:
    • SBL flags: lastAttendedDate is provided.
    • The attendance flagged is assumed.
    • The Instructional weeks count from the course start date to the lastAttendedDate.
  • Withdrawn Course (withdrawalDate is provided):
    • SBL flags: no lastAttendedDate is sent.
    • No weeks are counted. Withdrawn courses do not count towards the Registration based weeks, and with no lastAttendedDate present, there would be no Attendance based weeks either.
  • Withdrawn Course:
    • SBL flags: lastAttendedDate is provided.
    • Instructional weeks count from the course start date to the lastAttendedDate.


Assumptions Regarding Attendance

There are cases when a school cannot send daily attendance. Therefore, Regent Award will assume attendance for courses in specific cases.

  • If a course is not withdrawn, the course's quality points value is greater than "0," and completed=true, Regent Award assumes that the entire course was attended (attendance=true).
    • If the course end date has not occurred yet, Regent Award only assumes the last attended date through the SBL created date.
  • The following is specific to modules:
    • If the course start date is in the past, the course end date and the Expected Attendance Date are in the future, and there is no withdrawal flag, Regent Award is going to assume that the student is attending the course, even if the school has not sent the attendance flag or a last attended date. 


Furthermore, when appropriately configured, Regent Award can assume attendance for a student throughout an entire term when only one indication of attendance has been provided on the SBL, or via course overrides. See the Regent Award User Guide's section on the "Assume Attendance" feature for more information.

Valid State or Province Values

 Click here to expand...


Valid Country Values

 Click here to expand...