PowerSchool SIS Delivery Options

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.