Skip to main content

Guardian Contact Updates

  • With Guardian Contact Updates enabled, changes made to a guardian's information flow through to Connect with each guardian file sync.

  • Each new sync is treated as the complete list of guardians and their student connections. Connect compares it to what already exists and applies the differences when it can confidently tell its the same guardian.

  • A guardian's Email and Phone act as their identity, as long as one of those still matches, other details can be updated safely.

  • When neither contact (email or phone) matches, Rooms can't be sure it's the same person, and instead treats the record as a new guardian rather than overwriting the old one.


What Guardian information can be updated via syncing?

Field

Updates via ingestion?

Behavior

Guardian Last Name

Yes

Updated whenever the guardian is matched by their email or phone.

Guardian First Name

No (not via ingestion)

Not changed by guardian ingestion; captured when the guardian is first created. It can be edited directly in Connect by a district user with User Management access.

Guardian Email

Conditionally

Updated if the phone on file stays the same (the phone confirms identity). If email is the guardian's only contact, changing it creates a separate guardian instead of updating.

Guardian Phone Number

Conditionally

Same rule as email, reversed: updated if the email stays the same; changing a guardian's only contact creates a separate guardian.

Adding a missing Email or Phone

Yes

Filling in a blank contact while the existing one stays is applied.

Removing one contact

Yes

Clearing one contact while the other remains removes just that contact; the guardian and their guardianships stay in place.

A Guardian–Student record no longer in the data

Deactivates that Guardianship

When neither email nor phone appears for a given guardian–student record — whether both contacts were cleared or that record was dropped from the file — Connect deactivates that specific guardian–student relationship. It does not touch the guardian's relationships to their other students.


Two rules that prevent most surprises

  1. Change contacts one at a time. Changing a guardian's email and phone in the same ingestion, or changing the only contact a guardian has creates a second, separate guardian record rather than updating the existing one.

  2. Each email and phone belongs to one guardian. The same email or phone can't be assigned to two different guardians. An attempt to do so is skipped.


Ingestion reports (Activity Log)

  • Data Managers can view Guardian ingestion reports in the Activity Log within Campus Management.

  • Each report details the contacts that were updated, the guardianships that were created or deactivated, and any validation errors encountered including where a guardian could not be created due to conflicting information, and where a guardian could not be updated due to conflicting information or because the contact was already in use by another existing guardian.


Frequently Asked Questions

Why didn't a guardian's first name update?

First names aren't changed by guardian ingestion, they're set when the guardian is first created. To correct one, a staff member at your district with User Management access can edit it directly in Connect. (Not everyone has this access; it's granted to specific staff.)

I updated a guardian's email and now there are two guardians. Why?

The email (or phone) is how Connect recognizes a guardian. If you change the only contact a guardian has, or change both their email and phone at once, Rooms can't match the update to the existing guardian and creates a new one. Change one contact at a time, and keep at least one contact unchanged, so the update lands on the existing record.

Can I change a guardian's phone number?

Yes, as long as the guardian also has an email on file that stays the same. That email confirms it's the same guardian while the phone changes. If the phone is their only contact, changing it will create a separate guardian instead.

Why was my update skipped / not applied?

The most common reasons: the same guardian appears more than once in the file with conflicting names or contacts; the new email or phone is already assigned to a different guardian; or the change was to a first name (which never updates via ingestion).

A guardian's phone disappeared, did the update work?

If you cleared one contact and the other remained, that's expected the cleared contact was removed and the guardian stays in place. If neither contact appears for a guardian on a given student (both cleared, or that record dropped from the file), that guardian's relationship to that student is deactivated. If the guardian is still present for their other students, those relationships continue unchanged.

A guardian shows for some of their students but not others, is that a bug?

No. Each guardian–student relationship is handled independently. If a guardian was dropped from one student's data but still appears for others, they're correctly removed from the one and kept on the rest.

How can I see what changed, or why something was skipped?

Data Managers can open the Guardian ingestion report in the Activity Log under Campus Management. It lists the contacts that were updated, the guardianships created or deactivated, and any validation errors, including a guardian that couldn't be created because of conflicting information, or a guardian that couldn't be updated because of conflicting information or because the contact was already in use by another guardian.

How soon do changes take effect?

On your next guardian ingestion. Nothing changes mid-ingestion.

Can I merge two guardian records?

Not through guardian ingestion. If a duplicate was created, that's a support request.

What happens if a guardian is linked to a student that isn't in Rooms?

That record is dropped no relationship is created for a student that doesn't exist.

Why can't a guardian sign in after I updated their info?

If a contact change created a separate guardian record, the guardian's original access is tied to the original record. This is a duplicate situation and should be directed to support.

Did this answer your question?