Guardian Data Synchornization

Schools who send guardian data to SchoolMessenger will find the following logic is used to determine if a contact should be passed to SchoolMessenger and associated to a given student:

Restriction

Reasoning

Example

1. Don’t pass the contact unless the relationship they are assigned is considered “Is Parent” – you can modify which relationships are marked as this at Maintenance>Census>Relationship

Schools have pretty consistently asked that only contacts considered to be parents, be included in the contacts that get sent

2. Don’t pass the contact unless their “Receives Mail” checkbox is checked

By including this as a restriction, it allows schools to individually choose to EXCLUDE a parent on an as needed basis – it also follows the logic that if a contact is not marked to “Receive Mail”, they then also shouldn’t “Receive Calls”

3. In situations where the “Custody Alert” flag is checked

--AND--

A custody type is specified, DO NOT send contact information for the person if the Custody Type specified for the contact is “No Rights”



When any other custody type has been specified (or if the field is blank), contact information will pass (e.g. just the Custody Alert Flag is checked --or-- the Custody Alert Flag is Checked and the Custody is 50/50).

It has proven VERY important to schools, that in situations where the custody type is “No Rights”, that no data for that contact be sent to SchoolMessenger even in situations where the contact is set to “Receive Mail”, and the relationship they have to the student is considered a “Parent”

4. In situations where the “Restricted View” flag is enabled, DO NOT send information for the contact to SchoolMessenger.

In circumstances where there may not be custody issues that would be applicable to document for a given contact, yet a desire to have them set to “Receive Mail” and they are considered a parent, this was created as an “all else fails” option that can be used to omit contacts from making their way to SchoolMessenger as needed.


Data Mapping

The following table lists out the guardian data that is provided to SchoolMessenger by the Schooltool Data Sync program, and provides a brief explanation of where each data item comes from in Schooltool:

=>This document contains a printable version of the information in the table below.


Column ID

Data Column Name

Schooltool Field and Data Description

SchoolMessenger Guardian Record Screen

UniqueID

Unique Parent ID Issued by Schooltool (cannot be edited)

For more information on Managing Phone Numbers, Types and Ranks, see this article: https://www.edutech.org/resources/student-systems/...

FirstName

Contact’s First name

LastName

Contact’s Last Name

Language

"1st Language" represents the contact's Primary Language
N/A

Guardian Category

This represents the relationship a given contact has to a student (i.e. Mother, Father, Step Mother, Step Father)

Address 1

The first line of the Street Address assigned to the contact

Address 2

The second line of the Street Address of the contact

City

The City of the Home Address of the contact

State

The State of the Home Address of the contact

Zip

The Zip of the Home Address for the contact

Phone 1

Phone Number for the contact with Rank 1 in Schooltool

Phone 2

Phone Number for the contact with Rank 2 in Schooltool

Email 1

Contact’s Email Address

Email 2

Not Used: Schooltool only is capable of storing one email address per contact by default.

SMS 1

Same as Phone 1 above, assuming it's "Type" the number in Schooltool is set to "Cell - SMS"

SMS2

Same as Phone 2 above, assuming it's "Type" the number in Schooltool is set to "Cell - SMS"

Dependents

The dependents that appear the bottom of guardian records are only those students whom have a relationship to the contact where the relationship matches the criteria at the top of this article