Skip to main content
Skip table of contents

PowerSchool SIS Delivery Options

Delivery Target Configuration

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

Configuration Options

Common Configuration Options

Configuration OptionDescription
TitleUnique and identifies it as API delivery.
Associated Data ViewThe data view is linked to this delivery target. Most of the time, this is the Pending Delivery View.
Target TypeSet to PowerSchool API.
Delivery Time ZoneThis allows the fields *BATCH_CREATION_DATE* and *CURRENT_DATE_WITH_ZEROS* to be converted from Central Time (the default) to the designated time zone. This value is calculated on delivery and based on the option selected.
Allow Unapproved Records

This configuration option allows unapproved records to be eligible for delivery. Generally, a submission record must be approved in the submission record workflow to be eligible for delivery to a SIS. This option is rarely used.

Records do not need to be approved to show in the Pending Delivery view but they will still be removed from the Pending Delivery view once delivered. Note that a record does not appear in the Delivered view until it has been both delivered and approved.

Attempt Match for Unmatched Contacts within BatchThis setting allows for the ability to deliver siblings within the same batch and have contact matching for all students within that batch. If this feature is not enabled, siblings within the same batch that have the same contacts (newly created in the SIS) will result in duplicate contact records.
API Configuration Define the External API Configuration.
Deliver Now Enabled This feature allows users to initiate the matching processes and deliver data to the SIS without the batch creation process outside of the standard data delivery workflow. In actuality, it creates delivery batches for individual records behind the scenes. If there are any potential matches or errors that need to be resolved, the user is directed to the delivery review page as part of the normal data delivery workflow. This uses the same data delivery code as the standard data delivery workflow. This option is very rarely used.
Permissive Delivery Enabled

This configuration option allows delivery of schemas with a match status of Potential Match and, in doing so, creates new records, effectively assuming a decision of No Match. This is primarily used by a small number of customers that do not want to take on the administrative burden of manually reviewing and resolving potential matches. PowerSchool advises customers not to use this option.

In the standard data delivery process, if any delivery schema (for example, student or contact) has a match status of Potential Match, the delivery of that record is prevented, forcing the user to decide to either match the schema to one of the potential matches (which will match to and update that record) or indicate that the schema is not a match for any of the potential matches (which will create a new record).

Matched Students are UndeliverableThis option only works with Deliver Now. In the standard data delivery process, the matched record is updated if there is a student schema with a match status of Match. This configuration option prevents the delivery of the record if the student schema has a match status of Match, preventing an existing student record from being updated. This is used within new, student-only forms as an additional method of preventing returning or existing students from registering or enrolling through a new student process. This option is rarely used.
Disable Protective ChecksThe box should be unchecked to activate this feature. This configuration option, when enabled, allows delivery of any matched student schema regardless of first name, last name, or date of birth. In the standard data delivery process, if a student schema is matched to a student record in the SIS, but the first name is not an exact match, the last name is not an exact match, or the date of birth is not an exact match, the delivery of the record is prevented. This is referred to as Protective Checks and is intended to prevent the overwriting of student data with another student's data. PowerSchool recommends using this option for all clients using PowerSchool API delivery.
Use Pre-assigned Student Numbers for New Students This configuration option uses an ID provided by Enrollment in the payload as the ID of the newly-created student record. In the standard data delivery process, if a new student is created, the ID (student number) of that new student record is generated by the SIS.
Prohibit New Student Creation Works with both API and Deliver Now. This configuration option prevents the delivery of the record if the student schema has a match status of No Match, preventing a new student record from being created. This is used within returning or existing student-only forms as an additional method of preventing new students from registering or enrolling through a returning or existing student process. In the standard data delivery process, a new student record is created if there is a student schema with a match status of No Match. This option is rarely used.
Include Inactive Students

Works with Manual Delivery, Deliver Now, and Submissions Workspace Matching. This configuration option is only available for PowerSchool SIS version 20.4.1.0 and later. It delivers to inactive students within the PowerSchool SIS and potentially re-enrolls them. Select this toggle to match inactive students. The delivery match window will include enrolling statuses of Active, Inactive, Transferred-Out, and Pre-Registered students.

A versioning check automatically determines the version of PowerSchool SIS with inactive student matching and delivery. The check is as follows:

  • If the version is earlier than 20.4.0.0, the delivery occurs using the old endpoint.
  • If the version is 20.4.0.0 or before 20.4.1.0, there is an additional call to the new Enroll Student endpoint to verify if it is present. If present, the new endpoint is used for delivery. Otherwise, the old endpoint is used.
  • If the version is 20.4.1.0 or later, the new endpoint is used for delivery.
Conditional Update of Non-Custodial Contacts

This configuration option adds a condition to the update.

  • If the contact has a custodial relationship with the student (the custody flag is enabled on the active relationship), the record will always be updated.
  • If the contact does not have a custodial relationship with the student and the contact does not have a custodial relationship with any other student in the SIS, the record will always be updated.
  • If the contact does not have a custodial relationship with the student and the contact does have a custodial relationship with at least one other student in the SIS, then only the relationship between the contact and the student will be updated. This is to ensure that only the form submissions related to custodial relationships have ownership over the contact's data and to prevent scenarios where a contact's information was updated through their child's form submission and their 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).

In the standard data delivery process, when a contact schema is matched to a contact record in the SIS, the matched record will be updated in all cases.

Include Inactive Contacts

Works with Manual Delivery, Deliver Now, and Submissions Workspace Matching. This configuration option is only available for PowerSchool SIS version 20.4.1.0 and later. It delivers to inactive contacts within the PS SIS. Select this toggle to match inactive contacts and the delivery match window will include enrolling statuses of Active and Inactive contacts.

A versioning check automatically determines the version of PowerSchool SIS with inactive student matching and delivery. The check is as follows:

  • If the version is earlier than 20.4.0.0, the delivery occurs using the old endpoint.
  • If the version is 20.4.0.0 or before 20.4.1.0, there is an additional call to the new Enroll Student endpoint to verify if it is present. If present, the new endpoint is used for delivery. Otherwise, the old endpoint is used.
  • If the version is 20.4.1.0 or later, the new endpoint is used for delivery.
Create New Relationships when Relationship Details Change

This configuration option, when enabled, adds conditions to the update. If there is a change in one of the following relationship data points, the active relationship will have an end date applied to it and a new relationship will be created: relationship, custody, emergency, lives with, school pickup, receives mail, exclude from state reporting.

In the standard data delivery process, when delivering contact data, any existing active relationship between the contact and the student is updated.

End Relationships with Old Contacts with Following Contact Types

The configuration of this option allows the user to specify a list of relationship types. If there are any contacts with active relationships with the student in the SIS with one of those relationship types that were not included in the form submission, those relationships will have an end date applied. It is common to have this set to Not Set, which will apply this behavior to active relationships that do not have a relationship value defined.

In the standard data delivery process, contacts not included in the form submission are left alone in the SIS. This configuration option will end the relationships between the student and certain contacts.

End Old Contact Addresses This configuration setting offers options for handling old contact addresses (addresses not included in the form submission). The default setting is Only Used Types, which will apply end dates to all addresses not included in the form submission that match the address type of one of the addresses included in the form submission. The other setting for this option is All Types, which will apply end dates to all addresses not included in the form submission.
Remove Old Contact Phones

This configuration setting offers options for handling old contact phones (phones not included in the form submission).

  • No (Default): Does not remove any phones from the contact.
  • Only Used Types: Removes all phones from the contact not included in the form submission that match the phone type of one of the phones included in the form submission.
  • All Types: Removes all phones from the contact not included in the form submission.
Remove Old Contact Emails

This configuration setting offers options for handling old contact emails (emails not included in the form submission).

  • No (Default): Does not remove any emails from the contact.
  • Only Used Types: Removes all emails from the contact not included in the form submission that match the email type of one of the emails included in the form submission.
  • All Types: Removes all emails from the contact not included in the form submission.
Auto-Match to Contact when One Exact Match Found

This configuration option allows for the contact 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. Use this feature to reduce the amount of administrative burden of reviewing and resolving potential matches for the contact schema manually.

In the standard data delivery process, if there is no ID present for a contact, there is no pathway for that contact schema to be matched to a record automatically.

Ignore Address Component of Contact Matching when Address Not Present

xxxxxx

A versioning check automatically determines the version of PowerSchool SIS with enhanced matching criteria. This check is as follows:

  • If the version is 20.11.0.0 or later and Enhanced Match Criteria is enabled in the API configuration, the batch load and match window use the enhanced match criteria to display the students.
  • If the version is earlier than 20.11.0.0 or Enhanced Match Criteria is disabled in the API configuration, the batch load and match window use the old match criteria to display the students.
Only Match to Contacts Already Linked to Student

This configuration option limits that scope to only those active contact records already linked to the student. This feature ensures that each contact without an ID is created anew when creating a new student record. However, if a contact ID is present and matches a contact record in the SIS, that contact record will be matched to and updated, whether it was linked to the student already or not. This is used by customers who wish to manage a set of contacts on a per-student basis, effectively ignoring the many-to-many relational data structure implemented by Student Contacts.

In the standard data delivery process, the entire set of active contact records in the SIS is considered part of contact matching. This option is very rarely used.

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 first name, last name, address line 1, email address, and phone number. This configuration option is only available for PowerSchool SIS version 20.11.0.0 and later.

A versioning check automatically determines the version of PowerSchool SIS with enhanced matching criteria. This check is as follows:

  • If the version is 20.11.0.0 or later and Enhanced Match Criteria is enabled in the API configuration, the batch load and match window use the enhanced match criteria to display the students.
  • If the version is earlier than 20.11.0.0 or Enhanced Match Criteria is disabled in the API configuration, the batch load and match window use the old match criteria to display the students.
Auto-Match to Student when One Exact Match Found

This configuration option is only available when the Enhanced Match Criteria option is selected. The option is only available for PowerSchool SIS version 20.11.0.0 and later. 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 that matching criteria.

A versioning check automatically determines the version of PowerSchool SIS in relation to enhanced matching criteria. This check is as follows:

  • If the version is 20.11.0.0 or later and Enhanced Match Criteria is enabled in the API configuration, the batch load and match window use the enhanced match criteria to display the students.
  • If the version is earlier than 20.11.0.0 or Enhanced Match Criteria is disabled in the API configuration, the batch load and match window use the old match criteria to display the students.
Document Matching

This option is only available for PowerSchool SIS version 20.4.5.0 and later. The configuration has two settings:

  • Automatic: When the record is matched to an existing student in PowerSchool 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 PowerSchool SIS during data delivery.
  • Manual: When the record is matched to an existing student in PowerSchool 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 PowerSchool SIS during data delivery. You can manually match the document by clicking the Match button.

The algorithm for document matching and delivery is as below:

Document matching and delivery algorithm

A versioning check automatically determines the version of PowerSchool SIS in relation to document matching and delivery. The check is as follows:

  • If the version is 20.4.5.0 or later and Document Integration is enabled in the API configuration, the delivery occurs using the endpoint.
  • If the version is earlier than 20.4.5.0 or Document Integration is disabled in the API configuration, the delivery will be invalid, and the delivery batch creation produces an error as the API does not support document delivery.
Calculate Original Contact Types When selected, this configuration option enables the Original Contact Type calculation. The calculation determines the value to be sent for the relationship or original Contact Type field for each contact schema. The original contact type is a field used in PowerSchool SIS to relate a contact record to PowerSchool's legacy mother, father, guardian, and emergency contact fields.
Alternate Father Values This configuration option is only available if the Calculate Original Contact Types option is selected. It allows the user to define a comma-delimited list of contact relationships that can be used as the alternate value for determining the father's original contact type.
Alternate Mother Values This configuration option is only available if the Calculate Original Contact Types option is selected. It allows the user to define a comma-delimited list of contact relationships that can be used as the alternate value for determining the mother's original contact type.
Disable Deliver All Records Mode Removes the Deliver All button from the Data Delivery page, so each record must be delivered individually.
Use Power Queries Utilizes enhanced background logic to speed up the matching process. This setting should be used by all districts.

Health Integration Configuration Options

Configuration OptionDescriptionSchema
Set 'Show Concern in Alert' to False

This option ensures that each newly created health concern is not shown in the health alert for the student in PowerSchool SIS until it is reviewed and enabled by the nurse.

  • When selected and a new HealthConcerns record is created, the "Show Concern in Alert" setting is set to False, regardless of what is defined in the delivery schema items.

  • When selected and an existing HealthConcerns record is updated, the "Show Concern in Alert" setting is left untouched, regardless of what is defined in the delivery schema items.

  • When not selected, whatever is defined in the showConcernInAlert delivery schema item is respected.

Health Concerns
Set 'Show Comment in Alert' to False

This option ensures that each newly created or updated Health Concern comment is not shown in the health alert for the student in PowerSchool SIS until it is reviewed and enabled by the nurse.

  • When selected and the Narrative (comment) is added to a new Health Concerns record, the "Show Comment in Alert" setting is set to False, regardless of what is defined in the delivery schema items.

  • When selected and the Narrative (comment) is updated on an existing Health Concerns record, the "Show Comment in Alert" setting is set to False, regardless of what is defined in the delivery schema items.

  • When selected and the Narrative (comment) is not added or updated on an existing Health Concerns record, the "Show Comment in Alert" setting is left untouched, regardless of what is defined in the delivery schema items.

  • When not selected, whatever is defined in the showCommentInAlert delivery schema item is respected.

Health Concerns
End Old Health Concerns

This option ensures that any existing health concern records for the student not included in the form submission have a StopDate applied to them, assuming they are no longer relevant.

  • When selected, any existing health concern records for the student not otherwise created or updated as part of the delivery will have a StopDate applied with the current date. If a record already has a StopDate in the past or a StartDate in the future, a StopDate is not applied.

  • When not selected, any existing health concern records for the student not otherwise created or updated as part of the delivery are left untouched.

Health Concerns
End Old Medications

This option ensures that any existing Health Medication records for the student not included in the form submission have an EndDate applied to them, assuming they are no longer relevant.

  • When selected, any existing Health Medication records for the student not otherwise created or updated as part of the delivery will have an EndDate applied with the current date. If a record already has an EndDate in the past or a StartDate in the future, an EndDate is not applied.

  • When not selected, any existing Health Medication records for the student not otherwise created or updated as part of the delivery are left untouched.

Health Medication
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.