SSP Configuration Blocks

• 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

• 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

• 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.

• 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

• Reports and the Accommodation tool are the most commonly customized to allow individual access

• The student search uses data in this table.  For each term with a course count greater than zero

• Students may have multiple rows, one for each declared program
• The academic programs are display only and not connected to MAP

• 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. 

• 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

• Any test data can be stored in the table along with the outcome
• An integration to Smarter Measures test reports can be configured

• 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

• 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

• 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.

• 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.

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

• Student Intake Task Email

• 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

• 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

• Early Alert Confirmation to Advisor
• Early Alert Confirmation to Faculty
• Early Alert Journal Entry
• Early Alert Response to Faculty from Coach
• Early Alert Response to Referral Source from Coach
• Early Alert Sent to Student
• Early Alert Response Required Reminder to Coach

• 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

• 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.

• 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

• 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

• Action Plan Email
• Action Plan Step Email
• Contact Coach Email
• Custom Action Plan Task Email

• 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

• 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