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

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

• 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

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

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

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

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

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

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

• 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

• MAP Plan Full Printout

• MAP Template Printout

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

• The programs populate the program combo box filter used to select courses. The programs are not used for any other function in MAP.

• TAGS are only used to filter courses. The TAGs are not used for any other function in MAP.

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

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

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

• This is only used when the plan status calculation is turned off.

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

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

Considerations

• 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