eSchoolPlus Delivery Options

Delivery Target Configuration

The eSchoolPlus API needs a separate data delivery target. Contact PowerSchool Enrollment Support to set up your delivery target configuration options.

Configuration Options

Common Configuration Options

This table includes common configuration options for the data delivery target.

Configuration Option	Description
Title	The title for the delivery target.
Associated Data View	The data view linked to this delivery target. Most of the time, this is the Pending Delivery view.
Target Type	Set to eSchoolPLUS API. Note that “eSchoolPLUS DDA” is a valid option—this is the target type for using the old implementation of the eSchoolPlus integration.
Delivery Time Zone	The time zone of the server accepting the delivery of data.
Allow Unapproved Records	Generally, a submission record must be approved in the submission record workflow to be eligible for delivery to a SIS. This configuration option allows unapproved records to qualify for delivery. This option is rarely used.
Attempt Match for Unmatched Contacts within Batch	In the standard data delivery process, the match status of each schema at the time of delivery dictates the result: a Match results in the update of the matched record, and a No Match results in the creation of a new record. This configuration option performs matching on contact schemas with a match status of No Match at the time of delivery to find new potential matches that did not exist when the current match status was determined. The feature locates the potential matches and compares them to the previous list of potential matches for that schema. If new potential matches are found, the delivery is prevented, and the user must review and resolve the potential matches. This allows you to identify potential matches for contacts you may have created earlier in the batch’s processing. For example, two new student siblings contain submissions within the same delivery batch. Upon initial matching during batch creation, the parents did not yet exist in the SIS, but when one of the submissions is delivered, the parents do exist in the SIS and you do not want to create new records for them again.
Enable Protective Checks	When this setting is selected, student matching logic is altered such that any would-be match or potential match is further required to be an exact match on the first and last name and the date of birth. This prevents you from overwriting student data with another student’s data.
Include Inactive Students	This setting is used on and after eSchoolPlus version 19.11.5.0 and Enrollment version 20.5.0.0. Before these versions, matching records of all student statuses were included. When this setting is selected, it includes Inactive, Active, and Pre-Registered Student statuses. When not selected, it filters out the Inactive students and includes only the Active and Pre-Registered students.
Remove Old Student Phones	This configuration setting offers options for handling old student phones (for example, phones not included in the form submission). No (Default) – Does not remove any phones from the student. Only Used Types – Removes all phones from the student that match on phone type to any phone within the delivery record that has an empty phone number (for example, a phone type of “Work” is present within the delivery record, but the associated phone number value in the delivery record is empty). All Types – Removes all phones from the student not included in the form submission.
Remove Old Contact Phones	This configuration setting offers options for handling old contact phones (for example, phones not included in the form submission). No (Default) – This setting does not remove any phones from the contact. Only Used Types – Removes all phones from the contact that match on phone type to any phone within the delivery record that has an empty phone number (for example, a phone type of “Work” is present within the delivery record, but the associated phone number value in the delivery record is empty). All Types – Removes all phones from the contact not included in the form submission.
Display Student Location	This setting applies to the Delaware DELSIS Integration. When selected, it displays the source of the student record (found in the local eSchoolPlus database or in an external source database such as DELSIS) on the Data Review page or in the Match window. On the Data Review page, the source location details are appended to the Existing Data header. For example, the source location is expressed as "Existing Data (DELSIS)" when the student record is located in DELSIS and not in the eSchoolPlus local database, and as "Existing Data (Local SIS)" when the record is located in the eSchoolPlus local database. When a student record is found in both the local eSchoolPlus database and in DELSIS, the source is displayed as Local SIS. In the Match window, the Location column displays the student record location (Local SIS or DELSIS).

Simplified Match Logic Enabled

The Simplified Match Logic configuration option alters the contact matching logic and additional configuration options. When enabled, contact matching logic looks at the contact ID or a begins-with match on the first initial, a begins-with match on the last name, and either an exact match on any phone, an exact match on any email, or a “soft” match on any address.

The following table contains relevant configuration options when Simplified Match Logic is enabled.

Configuration Option	Description
Student Scope	Used in the standard data delivery process (using Simplified Match Logic). No — Contact matching behaves without Student Scope enabled. Yes — Contact matching considers any contact records that are already linked to the student as potential matches, both on batch load and match window: If a contact schema has a contact ID that leads to a definitive match to a contact record in the SIS that is not yet linked to the student, that is acceptable. If a contact schema does not have a matching contact ID to any record in the SIS, it only searches for potential matches from the set of contact records already linked to the student. If the student schema is not yet matched, all contact schemas have a match status of No Match, and there are no results in the Match window, with the exclusion of contact schemas that already have a matching ID. C & O Contact Types — Contact matching behaves as if Student Scope is enabled when sending a C or O-type relationship but is disabled when sending a G-type relationship. If a contact ID is present in the delivery record, the related contact record in the SIS based on the contact ID will still be matched to and appear in the match window regardless of what relationship type is being sent and what relationship types the contact has in the SIS. When matching a contact with a G-type relationship, matching considers every contact record in eSchoolPlus with only G-type relationships. Any contact with at least one C or O-type relationship is not considered. When matching a contact with a C or O-type relationship, matching considers only those contact records in eSchoolPlus already linked to the student with only C or O-type relationships. Any contact with at least one G-type relationship is not considered.
Auto-Match to Contact when One Exact Match Found	In the standard data delivery process (using Simplified Match Logic), if there is no ID present for a contact, there is no pathway for that contact schema to automatically be matched to a record. This configuration option provides a pathway for contact schemas without IDs to be matched to a record automatically as long as it passes more stringent matching criteria and as long as it is the only record that passes the matching criteria. Use this feature to reduce the administrative burden of reviewing and resolving potential matches for contact schemas manually. However, this feature should only be enabled for customers who understand the risk of false positives after consultation.
Conditional Update of Contacts by Contact Type	In the standard data delivery process (using Simplified Match Logic), when a contact schema is matched to a contact record in the SIS, that matched record will be updated in all cases. This configuration option adds a condition to that update. If the contact has a relationship with the student with contact type G (Guardian), then the record will always be updated. If the contact has a relationship with the student with contact type C (Contact) and the contact does not have a relationship with any student with contact type G, then the record will always be updated. If the contact has a relationship with the student with contact type C and the contact does have a relationship with any student with contact type G, then only the relationship between the contact and the student will be updated. If the contact has a relationship with the student with contact type O (Other Contact) and the contact does not have a relationship with any student with contact type G or C, then the record will always be updated. If the contact has a relationship with the student with contact type O and the contact does have a relationship with any student with contact type G or C, then only the relationship between the contact and the student will be updated. This ensures that only the form submissions related to higher hierarchical relationships have ownership over the contact’s data. It also prevents scenarios where a contact’s information was updated through the child’s form submission and the information was later updated to an incorrect or out-of-date value through another student’s submission (for example, as an emergency contact or neighbor).
Unlink Old Relationships	Use this option to remove relationships between students and contacts not otherwise created or updated as part of the data delivery process. When enabled, if a contact has multiple relationships to the same student (for example, a G-type and C-type relationship), when the contact is updated via the API, the relationships connecting this contact to the student that are not sent from Enrollment are removed. For example, Enrollment would send a relationship of type G and remove a preexisting relationship of type C.
Unlink Old Contacts	In the standard data delivery process (using Simplified Match Logic), contacts that are not included in the form submission are left alone in the SIS. This configuration option will remove the relationship between the student and any contacts not included in the form submission.
Delete Orphaned Contacts	This configuration option only appears when Unlink Old Contacts is enabled. When this configuration option is enabled, any contacts that have been unlinked from the student that no longer have a relationship with any student are deleted from the SIS.
Enhanced Match Criteria	When enabled, the matching logic uses an enhanced algorithm to find the exact and potential match. For student matching, it uses student ID, first name, last name, and date of birth. For contact matching, it uses the first name, last name, address line 1, email address, and phone number. This configuration option is only available for eSchoolPlus version 20.4.12.0+.
Auto-Match to Student when One Exact Match Found	This configuration only appears when the Enhanced Match Criteria is enabled. The option is only available for eSchoolPlus version 20.4.12.0+. In the standard data delivery process, if there is no ID present for a student, there is no pathway for that student schema to be matched to a record automatically. This configuration option provides a pathway for student schema without IDs to be automatically matched to a record, as long as it passes more stringent matching criteria, and as long as it is the only record that passes the matching criteria.
Document Matching	This option is only available for eSchoolPlus version 21.4.15.0+. The configuration has two settings for document matching: Automatic – When the record is matched to an existing student in eSchoolPlus SIS, the attached documents for the student are automatically matched based on the GUID value of the document. If the record's documents are matched successfully, the right-hand side of the record details will display the corresponding data from eSchoolPlus SIS during data delivery. Manual – When the record is matched to an existing student in eSchoolPlus SIS, the attached documents for the student are automatically matched based on the GUID value of the document. If the record's documents are matched successfully, the right-hand side of the record details will display the corresponding data from eSchoolPlus SIS during data delivery. You can manually match the document by clicking the Match button.

Simplified Match Logic Disabled

When Simplified Match Logic is disabled, contact matching logic is defined separately per contact type—it is set independently for when Enrollment is sending a contact that has a relationship with the student with contact type G, C, or O. For each of these, the Match Scope can either be set to All Contacts or Student.

The following table contains relevant configuration options when Simplified Match Logic is disabled.

Configuration Option	Description
Potential Matches for Contacts	The default behavior within both All Contacts and Student match scope is for all contact schemas to be definitively matched or not matched upon batch creation, and for there not to be any match window to interact with for contact schemas. However, when Potential Matches for Contacts is enabled, it allows for contact schemas to have a match status of potential matches upon a batch creation and allows for interaction with a match window for contact schemas.
Match Scope	Match scope controls the matching logic used for contacts and is defined separately per contact type: All Contacts considers all contact records in the SIS for potential matches with the contact schema. Student considers only those contact records in the SIS that are already linked to the student for potential matches with the contact schema. This means that if the student schema has a match status of No Match, all contact schemas will also have a match status of No Match (unless they already contained a contact ID that matches a contact record in the SIS).
Guardian/Contact/Other Matching	Guardian Matching, Contact Matching, and Other Matching impact the contact matching logic by controlling what contact types any potential match is allowed to have and are defined separately per contact type: Guardian Matching is defined for contact types C and O. Contact Matching is defined for types G and O. Other Matching is defined for types G and C. You can set each of these configuration options to: Prohibited – If a contact type is set to Prohibited in relation to sending another contact type, then any contact records with a relationship with that prohibited contact type are excluded from being considered as a match. Targeted – If a contact type is set to Targeted in relation to sending another contact type, then any contact records with a relationship with that targeted contact type are included in being considered as a match, as long as they don’t also have a prohibited contact type. Allowed – If a contact type is set to Allowed in relation to sending another contact type, then any contact records with a relationship with that allowed contact type are included in being considered as a match, as long as they also have at least one targeted contact type and do not have a prohibited contact type. The contact type of the contact being sent is implicitly Targeted.
Unlink Old Contacts	In the standard data delivery process (not using Simplified Match Logic), contacts not included in the form submission are left alone in the SIS. This configuration option will remove the relationship between the student and any contacts not included in the form submission. This is defined separately per contact type.
Delete Orphans	This configuration option only appears when Unlink Old Contacts is enabled. When this configuration option is enabled, any contacts that have been unlinked from the student that no longer have a relationship with any student are deleted from the SIS. This is defined separately per contact type.
Enforce Single Links	Enforce Single Links impacts the contact matching logic by controlling what relationships any potential match is allowed to have and is defined separately per contact type. When enabled, only orphaned contact records (contact records not linked to any students) and contact records only linked to the student in question are included in being considered as a match. This is used to maintain a one-to-many relationship between the student and contacts, where the student can be linked to many contacts, but each contact can only be linked to a single student.
Update Only Existing Links	Update Only Existing Links controls how new contacts are handled and is defined separately per contact type. When disabled, as is the default, any contact schemas with a match status of no match will create a new contact records in the SIS. When enabled, any contact schemas with a match status of no match will not create a new contact records in the SIS. Instead, nothing is done with unmatched schemas. This configuration option is functional only when Match Scope is set to Student. This is to ensure that the only contacts touched in the SIS are those contacts already linked to the student.