Delivery Target Configuration
The eSchoolPlus API needs a separate data delivery target. Contact PowerSchool Enrollment Support to set up your delivery target configuration options.
Common Configuration Options
This table includes common configuration options for the data delivery target.
|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.
|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 126.96.36.199 and Enrollment version 188.8.131.52. 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).
|Remove Old Contact Phones
This configuration setting offers options for handling old contact phones (for example, phones 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.
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.
Used in the standard data delivery process (using Simplified Match Logic).
|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.
|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 184.108.40.206+.
|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 220.127.116.11+. 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.
This option is only available for eSchoolPlus version 18.104.22.168+. The configuration has two settings for document matching:
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.
|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 controls the matching logic used for contacts and is defined separately per contact type:
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:
You can set each of these configuration options to:
|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.
|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.