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 10
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.
Block 1 - Base SSP Configuration
External DB Tables
| external_person | Description |
|---|
| Purpose | Holds 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_term | Description |
|---|
| Purpose | Holds 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 Settings | General Settings | Counseling Reference Guide (CRG) | Journal Track-Step-Detail |
|---|
| Section 1 | Section 2 | Worksheet | Worksheet |
- Student ID Alias
- Coach Label
- Retrieve External Data
- Coach Query
- Coach Set from External Data
- Coach Unset from External Data
- Student Type Set from External Data
- Student Type Unset from External Data
- External Sync Schedule (multiple)
- Send Mail
- Test Mail Server Port
- BCC Email Address
- Manage Integration Database
- Status Code Mapping
- Highly Trust IPs
- Client Side Timeout
| - 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 darly and often in order to complete.
| - The Journal associations will take time to collect and organize. The worksheet should be distributed darly and often in order to complete.
|
uPortal Roles and Permissions
| Role Assignments | Description |
|---|
| Purpose | Each 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 Permissions | Descriptions |
|---|
| Purpose | Each role has a default set of tool permissions. Beyond assigning multiple roles, individual tool permissions can be assigned if necessary. |
| Considerations | |
Block 2 - Main Tool Phase 1
External DB Tables
| external_registration_status_by_term | Description |
|---|
| Purpose | Holds 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_program | Description |
|---|
| Purpose | Defines 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_transcript | Description |
|---|
| Purpose | Holds 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_term | Description |
|---|
| Purpose | Holds 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
- Continue collecting items for the Counseling Reference Guide
- Continue collecting items for the Journal Track-Step-Detail associations
Block 3 - Main Tool Phase 2
SSP Configuration Guide
- General Settings (FinAid)
- Financial Aid Files
- Financial Aid SAP Status Codes
External DB Tables
| external_student_test | Description |
|---|
| Purpose | Holds 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_course | Description |
|---|
| Purpose | Contains 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_aid | Description |
|---|
| Purpose | Holds 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_term | Description |
|---|
| Purpose | Holds 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_file | Description |
|---|
| Purpose | Holds 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 Settings
- Student Intake Message Template
- Intake Field Labels
Block 5 - Early Alert
External DB Tables
- external_faculty_course_roster
- external_faculty_course
SSP Configuration Guide
- Early Alert Settings
- Early Alert Message Templates
Block 6 - Journal
SSP Configuration Guide
- Journal Settings
Block 7 - Counseling Reference Guide and Action Plan
SSP Configuration Guide
- Action Plan Settings
- MyGPS
- Action Plan Message Templates
Block 8 - Map Phase 1
External DB Tables
- external_course
- external_division
- external_department
- external_program
SSP Configuration Guide
- MAP message templates
- MAP Settings
- MAP Plan Status Calculation
Block 9 - Map Phase 2
External DB Tables
- external_course_term
- external_course_program
- external_course_tag
- external_course_requisite
- external_substitutable_courses
- external_person_planning_status (optional)
SSP Configuration Guide
- MAP Settings
Block 10 - Notes and Accommodation
External DB Tables
- external_person_note
SSP Configuration Guide
- Accommodation Settings