Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Below is a recommended approach to dividing the configuration and corresponding external data into blocks of effort.  Based on the SSP tools to be implemented, the corresponding block(s) of effort can be scheduled into the project timeline.  The main goal of the block approach is to divide the effort into measurable segments of work that can be analyzed, executed and tested independently from other SSP tools.


Configuration and External Data Validation

ValidationDescription
PurposeFor each of the blocks described below, the configuration and external data should be validated for accuracy, integrity and support for the business processes.  The links below should be used to assist with validation for each block.  The external data is displayed throughout SSP as described in the User Interface Validation.  The documentation describes the location of external data in the UI.  The external data also is the basis for user information and supports various tools.  To ensure the supports the application, the validation queries will identify common problems with the data load in the external tables.
User Interface ValidationDocumentation of display locations for external data in the user interface
Data and Configuration ValidationCommon validation queries to test the accuracy of the configuration and integrity between external tables

 

Block 1 - Base SSP Configuration

External DB Tables

external_personDescription
PurposeHolds attributes for any user accessing or referenced by SSP. For example, supports search results, early alerting and student creation. Records in this table are periodically synchronized into the "person" table and several of its supporting tables. Both school_id and username must be unique identifiers for each record. I.e. any given school_id or username can occur at most once.
Considerations
  • All users who will sign into SSP or MyGPS should have a row in the table including;
    • All students that may be added to SSP
    • All coaches (counselors, faculty members, advisors, etc) that may be assigned as a coach for a student
    • All faculty members who may have an Early Alert rosters
  • Only students should have a coach_school_id and student_type_code
  • Commonly implementers add students to external data that are "system active" so that they are available to SSP.  The litmus test would be: "Could the student walk off the street and register for courses?".  If so they should be available to SSP in the external data.
  • The username must match the username that a user will use to log into SSP
Sync'd Fields
  • first_name
  • middle_name
  • last_name
  • birth_date
  • primary_email_address
  • username
  • home_phone
  • work_phone
  • cell_phone
  • address_line_1
  • address_line_2
  • city
  • state
  • zip_code
  • residency_county
  • photo_url
  • school_id
  • coach_school_id
  • office_location
  • office_hours
  • actual_start_term
  • actual_start_year
  • marital_status
  • ethnicity
  • gender
  • balance_owed
  • student_type_code
  • race_code
external_termDescription
PurposeHolds academic calendar information. Required in many locations throughout the application: Caseload Assignment, Main, Intake and MAP.
Considerations
  • term_code must be used consistently in other external database tables.  There are no foreign keys, but the data must have integrity by used consistent values.
  • Commonly implementers don't have exact dates for future terms.  In order for MAP to render to future terms in which coaches/advisors can develop plans, future terms may need to be fabricated until the exact terms.  Future terms should be fabricated for up to 5 years after the current academic year.  The dates should be arbitrary and won’t affect SSP if they are changed when the new dates are officially defined.  The following  are sample dates that can be used for the fabricated terms.
    • Fall: 8/15-12/15
    • Spring: 1/5-5/10
    • Summer: 5/15-8/1
  • registration_start_date and registration_end_date are only used for MAP

SSP Configuration Guide

Install SettingsGeneral SettingsCounseling Reference Guide (CRG)Journal Track-Step-Detail
Section 1Section 2WorksheetWorksheet
  • Student ID Alias should match the format of the school id used in the SIS
  • Coach Query must be updated if the coach role is assigning outside of SSP
  • Coach Set/Unset from External Data depends entirely on available assignments from the SIS
  • Student Type Set/Unset from External Data is most commonly sync'd from the SIS data and both set to true
  • Send Mail is generally set to false during testing so that users are not receiving emails.
  • Status Code Mapping is used in the Main  and Early Alert submissions tools
  • Student Types
  • Special Service Groups
  • Reasons for Service
  • Referral Sources
  • Program Status Change Reasons
  • Confidentiality Levels
  • The CRG will take time to collect and organize.  The worksheet should be distributed early and often in order to complete.
  • The Journal associations will take time to collect and organize.  The worksheet should be distributed early and often in order to complete.

uPortal Roles and Permissions

Role AssignmentsDescription
PurposeEach user must have a role assignment in order to log into SSP.  The default role for all users should be student which allows the least amount of access to SSP (specifically MyGPS)
Considerations
  • Users may have multiple role assignments.  Multiple assignments grant a combined access to tools
  • Roles can be assigned based on the security integration via CAS, LDAP, etc
  • Roles can be assigned locally in SSP and via the security integration
  • The coach role is important to establish as the available coach list in Caseload Assignment depends on users assigned the coach role
  • The faculty role is the only non-administrator role that can access the Early Alert submission tool
Tool PermissionsDescriptions
PurposeEach role has a default set of tool permissions.  Beyond assigning multiple roles, individual tool permissions can be assigned if necessary.
Considerations

Validation Steps

  • Add a new student to SSP
  • Review the sync'd data from external person
  • Confirm section1 and 2 configuration items

 


Block 2 - Main Tool Phase 1

External DB Tables

external_registration_status_by_termDescription
PurposeHolds registration status for each student by term. Used in SSP reporting capabilities.  Used in the Main Tool Details Tab
Considerations
  • The student search uses data in this table.  For each term with a course count greater than zero
external_student_academic_programDescription
PurposeDefines each student's current academic program(s) of study.  Used in the Main Tool Dashboard Tab
Considerations
  • Students may have multiple rows, one for each declared program
  • The academic programs are display only and not connected to MAP
external_student_transcriptDescription
PurposeHolds current, cumulative student transcript summary information.  Used in the Main Tool Dashboard Tab. Note that SSP will never attempt to calculate a GPA.
Considerations
  • It is important to ensure that totals in the transcript table match a sum of the external_student_transcript_term table (described below)
  • The corresponding fields in the user interface appear whether or not data exists. 
external_student_transcript_termDescription
PurposeHolds term by term student transcript summary information.  Used in the Main Tool Dashboard Tab. Note that SSP will never attempt to calculate a GPA.
Considerations
  • Data for each term can be cumulative or term specific only.  Implementers can choose either meaning for the data when populating the table, specifically GPA
  • Implementers most commonly load current and registered terms

SSP Configuration Guide

  1. Continue collecting items for the Counseling Reference Guide
  2. Continue collecting items for the Journal Track-Step-Detail associations

Block 3 - Main Tool Phase 2

SSP Configuration Guide

  1. General Settings (FinAid)
    • Financial Aid Files
    • Financial Aid SAP Status Codes

External DB Tables

external_student_testDescription
PurposeHolds student test score data.  Used in the Main Tool Placement Tab
Considerations
  • Any test data can be stored in the table along with the outcome
  • An integration to Smarter Measures test reports can be configured
external_student_transcript_courseDescription
PurposeContains section- or course-scoped student transcript records. Used in the Main Tool Transcript Tab. Each row represents a collection of course completion metrics (grade, credits earned, etc) for a particular student at at least course granularity (course code + term code). Additional values can be specified to scope a given entry to a particular section, but this may not be possible in all cases, e.g. transcript entries sourced from other institutions.
Considerations
  • Most implementers load current and future term registrations
  • Each row in the database should have a grade.  This is most important for the MAP plan status calculation process.  Planned courses will be evaluated by grade to determine the plan status based on a list of passing grades.  Null grades will not be considered during the calculation
  • credit_type = Transfer is the only significant value.  All rows with 'Transfer' as the value will be displayed as a total hours calculation on the Details tab
  • course_code is an optioned field for each row but must be populated from day 1 if the course_code matching criteria will be used in the plan status calculation
external_student_financial_aidDescription
PurposeHolds student financial aid information.  Used in Main Tool Details Tab
Considerations
  • The SAP Status Codes are defined in the configuration and matched with rows in the table to show the students current status along with the description configured.
  • gpa_20_b_hrs_needed/gpa_20_a_hrs_needed: the original intent is to give students an indication of what they would have to accomplish to achieve an A or B GPA .  A & B level will vary for each school.  Traditionally, they would indicate a GPA representing an A (4.0) or B (3.0) using a standard calculation of earned/attempted.
  • financial_aid_file_status is an overall status of all files in the external_student_financial_aid_file table
external_financial_aid_award_termDescription
PurposeHolds student financial aid information to describe the term by term acceptance of financial aid.  Each term financial aid was offered to a student should be included along with the acceptance status for each term.  Used in Main Tool Details Tab
Considerations
  • SSP will display the rows in the table.  Most commonly implementers load the table for each term a student is offered financial aid along with the acceptance for that term.
external_student_financial_aid_fileDescription
PurposeHolds student financial aid information related to the files required in the students application.  Each of the required files should be associated to a row for each student.  Each row should have an appropriate status code to describe the status of each file.  Used in Main Tool Details Tab and MAP
Considerations
  • Most commonly implementers configured each required file to apply for and receive financial aid.  Each file has an individual status that is displayed in list form.

Block 4 - Student Intake

SSP Configuration Guide

Student Intake SettingsStudent Intake Message TemplateIntake Field Labels
Section 3Section 8 with Template Definitions and ExamplesSection 3

Many of the intake settings should match the values available in the SIS.  Most common:

  • Citizenships
  • Education Goals
  • Education Levels
  • Ethnicities
  • Marital Status (sync'd from external_person)
  • Military Affiliations
  • Races (sync'd from external_person)
  • Veteran Statuses
  • Each of the Student Intake field labels can be customized for both SSP and MyGPS. 
  • The contact information sync'd from external_person are global configurations for the Intake and Main tools

Block 5 - Early Alert

SSP Configuration Guide

Early Alert SettingsEarly Alert Message Templates
Section 4Section 8 with Template Definitions and Examples
  • Although the Campus configuration is required, the optional email routing can be added later.  By default SSP will use the default coordinator definition when assigning any non-assigned student and notifying the coordinator by email.
  • The email routing allows for additional notifications based on the reason so that multiple persons/groups are emailed

External DB Tables

external_faculty_courseDescription
PurposeHolds information related to course details for each course taught by an instructor for a given term. Used along with v_/external_faculty_course_roster to support SSP Early Alert creation.
Considerations
  • The list of courses for each faculty member is based on data in this table.  In order for an Early Alert to be submitted, the faculty member must have at least one row in this table
  • All faculty_school_id values in this table must have a corresponding detail row in external_person
  • Most commonly implementers only load courses for the current term since alerts would not be submitted for past and future terms
external_faculty_course_rosterDescription
PurposeHolds course roster details for each course taught by an instructor. Used for SSP Early Alert. Each record in this table represents a selectable enrollment in the SSP Early Alert creation UI. For Early Alerts created directly via API, the application may attempt to locate additional course-related data from this table, but this is optional. Any data sourced from this table during Early Alert creation is copied into the Early Alert record, so this table can be periodically pruned, e.g. as a simple means to limit the selectable rosters in the Early Alert UI.
Considerations
  • The same scope for courses and terms apply for the roster table
  • The same tatus code mapping definitions used in the Main Tool Schedule Tab (rows in external_student_transcript_course) are translated for the roster rows during the Early Alert submission.

Block 6 - Journal

SSP Configuration Guide

Journal Settings
Worksheet
  • The Track-Step-Detail associations are are 100% based on completing the worksheet and entering the Tracks, Steps, Details and associations.  Once complete, the associations are available for selection when creating/updating Journal Entries

Block 7 - Counseling Reference Guide and Action Plan

SSP Configuration Guide

Action Plan SettingsMyGPSAction Plan Message Templates
Section 7WorksheetSection 8 with Template Definitions and Examples
  • The Action Plan is 100% based on completing the Counseling Reference Guide (CRG) worksheet and entering the Categories, Challenges, Referrals and associations.  The tasks are created based on selecting a Referral from the CRG
  • The Self-Help Guides (SHG) are 100% based on assigning existing Challenges to a SHG and providing the details of the purpose and order of Challenges

Block 8 - Map Phase 1

External DB Tables

external_courseDescription
Purpose

Holds course details generally found in a course catalog/bulletin.  Used in the MAP Tool

Considerations
  • The rows populate the Available Course List in MAP for users to select courses to add to Plans and Templates
  • The courses should contain courses for which the student can register. Older courses are generally not useful
  • Implementers have discovered more than 1500 courses does not perform well in the application
  • The course list is cached on the server which is updated once a day or during application startup

 

 

external_divisionDescription
Purpose

Defines the list of divisions that can be added to the plan template definition.  Used in the MAP Tool.

Considerations
  • The list of programs should only include academic divisions. The list of divisions is available in a combo box when defining Plans and Templates.

 

 

external_departmentDescription
Purpose

Defines the list of departments that can be added to the plan template definition.  Used in the MAP Tool.

Considerations
  • The list of programs should only include academic departments. The list of departments is available in a combo box when defining Plans and Templates.
external_programDescription
Purpose

 Defines the list of programs that can be added to the plan template definition.  Used in the MAP Tool.

Considerations
  • The program code defined should match the program codes used in other tables
    • external_student_academic_program
    • external_substitutable_courses
  • The list of programs should only include academic programs. The list of programs is available in a combo box when defining Plans and Templates.

SSP Configuration Guide

MAP SettingsMAP Message Templates
Section 11Section 8 with Template Definitions and Examples
  • 11.1 MAP Colors
  • 11.2 MAP Electives
  • 11.4 Anonymous Template Access
  • 11.10 Allow Edit of Past MAP Plan Terms
  • MAP Plan Printout

 


Block 9 - Map Phase 2

External DB Tables

 

external_course_termDescription
PurposeDefines the terms in which the designated course is offered.  Each course with the associated term to include is listed separately.  Used in the MAP Tool.
Considerations
  • MAP validates whether or not courses added to the plan are planned to be offered. Many implementers don't have future term assignments. When the information exists, the table should be populated with pairs of courses and terms. When the information doesn't exist, implementers commonly use two approaches:
    • Leave the table empty which will turn term validation off in MAP
    • Fabricate course-term assignments for future terms so users do not get validation error message. This does open a risk that courses will not be offered in future terms and thereby invalidating the course in the plan.
external_course_programDescription
PurposeDescription: Defines the courses required by degree programs.  Each course with the associated program is listed separately.  Used in the MAP Tool.
Considerations
  • The programs populate the program combo box filter used to select courses. The programs are not used for any other function in MAP.
external_course_tagDescription
PurposeDefines the tag codes assigned to courses.  Each course with the associated tag is listed separately.  Used in the MAP Tool.
Considerations
  • TAGS are only used to filter courses. The TAGs are not used for any other function in MAP.
external_course_requisiteDescription
Purpose

 Defines the list of programs that can be added to the plan template definition.  Used in the MAP Tool.

Considerations
  • MAP validates whether or not courses added to the plan have satisfied the requisite rules in defined in the table. No rows in the table essentially turns off the course validation.
  • The requisite rules allow for CO, PRE and PRE_CO but are limited to course pairs (2 course max)
external_substitutable_coursesDescription
PurposeDescription: Defines the relationship of courses that may be used during the MAP plan status calculation.  An option in the calculation allows for a planned course to be substituted by another course when the matching logic identifies courses.  When matched to the subtitution (target course), the planned course will be considered a match.  Each row will define a single pair of courses, and multiple rows can be inserted to define additional substitutions for a plan course.  Used in the MAP Tool
Considerations
  • Substitution rules must contain information for the source and target courses for each optional matching criteria is turned on. That include course title, course hours and course code.
  • When program code, term code and catalog year are not defined the substitution rules apply to all matching courses.
external_person_planning_status (optional)Description
PurposeDefines the status of the student's active plan.  Valid values are On and Off.  This indicates whether or not the student is on plan to complete the active plan.  The requirements and calculation of plan status is done outside of SSP and simply stored in this table.  If the student planning status is Off, a reason can be stored in the table.  Used in the MAP Tool when SSP is not calculating the plan status.
Considerations
  • This is only used when the plan status calculation is turned off.

SSP Configuration Guide

MAP Settings 

Section 11

MAP Plan Status Calculation

    • The details of the plan status calculation process are in the Users Guide.
  • 11.3 MAP TAGs
  • 11.5 Calculate MAP Plan Status
  • 11.6 MAP Plan Status Matching Criteria
  • 11.7 MAP Plan Status Cutoff Term
  • 11.8 MAP Plan Status Passing Grades
  • 11.9 Task Scheduler for MAP Plan Status
  • 11.11 MAP Plan Status Send Report
  • 11.12 MAP Plan Status Email Address
  • 11.13 MAP Plan Status Send Off Plan Coach Email
  • 11.14 MAP Plan Status Term Bound Strict
  • 11.15 MAP Plan Status Use Substitutable Courses
 

Block 10 - Notes and Accommodation

External DB Tables

external_person_noteDescription
PurposeNotes from any system can be save in the table for display in SSP.  Notes can originate from any system and will be displayed to the user in chronological order.  Used in the External Notes Tool
Considerations

By default, Notes are only available to Coach roles.  Implementers commonly add permissions to the Support Staff and Faculty roles

No security is applied to the rows.  If a user has access, all rows loaded into the table are visible are visible

SSP Configuration Guide

Accommodation Settings
Section 9

The Accommodation tool is used only to store application and disposition information.  Security for access to the tool should be considered for the Coach role

For any entries/records created in other SSP tools, the Confidentiality Level for Disability (or alternate) should be considered

 

 
 
 

  • No labels