Chat for district and site admins: Constituent data management

Avatar
Misty Flowers

This article details the constituent data that Finalsite Chat depends on, including how portal logins and relationships determine who joins a room, and what happens to chat access, room membership, and chat history when that data changes through deactivation, deletion, or reactivation.

Before you start

This article is for district and site admins and covers the constituent data behind Chat, including what happens when that data changes through deactivation, deletion, or reactivation on the backend. Are you in the Chat manager role? For day-to-day room management, check out the article: "Chat for Chat managers: Manage chat room membership."

💡 Quick answers

  • Where does chat room membership actually come from? From constituent data, not from Chat. A class chat room is the last link in a chain that starts in the source system and passes through Constituent Manager and Group Manager. A break anywhere upstream shows up in Chat.
  • Why can a room look wrong when the group looks right? A room created by adding members by group captured that membership once. It does not follow the group afterward. Only rooms built from Academic Classes with dynamic filters stay in sync.
  • What is the most common reason a class room never appears? No member of the Academic Classes group is designated as Admin. At least one Faculty/Staff member must be marked Admin.
  • Why are parents missing from every class room? Whether parents are added at all is governed by the "Create chat rooms with..." setting in Chat Settings. When Parents/Guardians is not selected, parents are not added even when correctly linked to a student. The setting is greyed out and Finalsite Support changes it on request.
  • Does a chat participant need a portal login? Yes. Every chat participant needs an active portal account with a username, and must be signed in to the app to reach Chat.
  • Does deactivating someone remove their chat access? Yes, right away. The chat account is turned off the next time Constituent Manager updates.
  • Will a deactivated person still show up as a member of a class room? Possibly, for a while, or indefinitely if the room does not sync at all. Losing access happens quickly, but a room's member list only refreshes on its own schedule.
  • Does deleting or purging a constituent delete their chat messages? No. Chat access is turned off, but the person's past messages remain visible in the rooms they belonged to.
  • If a deactivated person returns to the feed, does everything come back? Roles and chat access come back automatically. Relationship data does not, so a returning parent's connection to a child's class room may need to be rebuilt separately.

In this article

How chat membership works

The chain behind a chat room

Nearly everything you see in a chat room, including who belongs there, comes from data managed elsewhere in your systems. So when something looks wrong in a chat room, the real cause is almost always somewhere upstream, not in the Chat feature itself.

Layer What it supplies What breaks in Chat when it is wrong
Constituent record The person exists in Constituent Manager, with a role. The person cannot appear in any room. A duplicate profile splits their access across two records.
Portal login An active account with a unique username, and a working sign-in method. The person cannot reach Chat at all, whatever their room membership says.
Chat role District Admin, School Admin, Chat Manager, or Chat Participant. Chat reports no access, or the person can sign in but sees nothing.
Relationships The parent to student links that place guardians in a class room. The wrong guardian joins a room, or the right one is missing.
Group membership The Academic Classes group, its roster, and the Admin designation. The room is missing members, or is never created at all.
The room itself Whether the room tracks its group or holds a fixed snapshot. The group is correct and the room is stale, permanently.

Constituent records and portal logins

Every chat participant needs a constituent record and an active portal account with a username, typically an email address. Usernames must be unique across all roles. They are created either during a constituent datasheet upload, by filling in the username column, or individually in Constituent Manager through the Account tab.

Confirm a constituent can reach Chat

  • Step 1: Open the constituent in Constituent Manager and confirm the record exists with the expected role.
  • Step 2: Select the Account tab and confirm a username is present.
  • Step 3: Search Constituent Manager by name and by every known email address, to rule out a duplicate profile holding the memberships.
  • Step 4: Confirm which sign-in method the organization uses, and that the person is using it.

⚠️ Important Note

Turning single sign-on on or off changes how everyone signs in. A person who is signed out again 20 to 30 seconds after signing in is often still using the previous method. Plan sign-in changes deliberately, and tell chat users which method to use afterward.

Chat roles and visibility

Access to Chat is separate from constituent roles and from CMS permissions. It is governed by a chat role: District Admin, School Admin, Chat Manager, or Chat Participant. A separate visibility setting controls whether Chat is shown to parents or students at all.

When someone reports that Chat says they do not have access, and restarting and updating the app does not clear it, the cause is a role or permission rather than a fault. Either no chat role has been assigned, or Chat is hidden for that user type by design.

Who joins a class room

For rooms built from Academic Classes, membership is assembled from three sources.

  • Faculty and staff. Every Faculty or Staff member in the group must be designated as Admin. Anyone not designated does not sync to the room. They join as Chat Manager.
  • Students. Added as members of the class group. They join as Chat Participant.
  • Parents and guardians. Synced from existing student and parent relationships, but only when the "Create chat rooms with..." setting includes Parents/Guardians. They join as Chat Participant.

⚠️ Important Note

The "Create chat rooms with..." setting in Mobile Apps, under Chat Settings, decides whether students and parents are included at any class room. If only teachers are selected, students and parents do not sync even when they are correctly in the group with valid relationships. This setting is greyed out; contact Finalsite Support to change it.

A class group also needs a unique Import ID and a unique Group Name, and the chat room name field needs at least one data point selected, or no room is created.

Rooms that stay in sync, and rooms that do not

This is the most common source of confusion, because both approaches pull their initial members from a group and then behave completely differently.

Behavior Manually created room, populated by group Academic Classes group with dynamic filter
Initial members pulled from group Yes Yes
Updates when group membership changes No. One-time snapshot only. Yes. Syncs automatically.
Students and parents included No Based on the "Create chat rooms with..." setting
Best for Stable, custom-membership rooms Class rosters that change during the year

What changes chat membership

Deactivation

A constituent who stops appearing on the integration feed is deactivated through the off-feed utility, which removes them from the roles the feed populates and moves them to an Inactive role. Chat access is turned off the next time Constituent Manager updates. This part is prompt and reliable, and it is already visible in Chat: the Chat module's Overview counts exclude deactivated and deleted users.

Being removed from a room's member list is a separate step, and it does not always happen at the same time. A dynamically synced room follows its group and updates once that group changes; a room populated by a one-time snapshot does not follow it at all. Because of this, a deactivated person can still appear as a member of a class room for a while, or indefinitely in a snapshot-based room, after already losing access.

A constituent held only in the roles being compared also loses ClassOf, CurrentGrade, and relationship data. Because parent membership in class rooms is derived from relationships, this affects guardians as well as the departing person; see "Reactivate a returning family member" and "A parent connected to more than one child" below for what this means in practice.

Chat notifications follow a room's member list rather than whether someone is active. This means a person who still appears as a member can keep receiving chat notifications, including a preview of the message, even though opening the app sends them straight to a screen saying they do not have access. Notifications stop once they are actually removed from the room's member list. Muting a room stops its notifications for every member, regardless of this.

Someone whose chat access has been turned off can still open the chat app and try to sign in. In most cases they will not get past sign-in, since deactivation also clears the username on the account. If they do reach chat, they see a brief loading screen followed by a message that they do not have access, with no further explanation shown.

For anyone still messaging with a deactivated person, existing conversation history is not affected. The box for sending new messages becomes disabled, without an explanation. Deactivated people are also left out of member lists and member counts elsewhere in chat.

Deletion and purging

Records created by hand never appear in off-feed results, since they never came from a feed to begin with. Removing one of these constituents happens directly in Constituent Manager. A feed-sourced constituent already in the Inactive role is removed the same way, through a purge.

Either path turns off that person's chat access the same way deactivation does, and it can take a while to clear from a room's member list for the same reason.

⚠️ Important Note

Deleting or purging a constituent causes a permanent loss of some Finalsite-specific data, including personal files and login history. Chat messages are not part of that loss. Past chat messages remain visible in the rooms the person belonged to, still shown as sent by that person.

Remove someone directly in Chat Admin

Chat Admin also has its own Remove user action, separate from anything in Constituent Manager. This removes someone from chat immediately and keeps them from being added back automatically, even if their constituent record becomes active again later. Use Constituent Manager for anything related to enrollment or role changes, and reserve this action for cases where someone specifically needs to be kept out of chat going forward.

Compare what each action does

Action Chat access Chat messages Room member list Can this be reversed
Deactivated automatically (moved to the Inactive role) Turned off on the next update. Stay in place. May still show as a member for a while. Yes, if the person returns to the source feed.
Deleted or purged Turned off on the next update. Stay in place, still shown as sent by that person. May still show as a member for a while. No.
Removed directly in Chat Admin Turned off immediately. Stay in place. Removed immediately. No. Chat access does not come back automatically even if the constituent record becomes active again.

Reactivate a returning family member

When a deactivated constituent reappears on the source feed, roles and chat access come back automatically. Anyone with a chat room connected to an active group membership regains that room without any manual step.

Relationship data does not come back the same way. ClassOf, CurrentGrade, and relationship rows are cleared during deactivation, and returning to the feed does not restore them; they come back only if the source system supplies them again. Since a parent's connection to a child's class room comes from relationship data rather than group membership, that connection can stay missing even after the parent's chat access itself has been restored, until the relationship is re-established through a new data import. See "A parent connected to more than one child" below for what this means in practice.

A parent connected to more than one child

 Real-world scenarios

A parent's chat access can change in different ways depending on what actually happened to their record. Two situations come up most often.

  • The parent was fully deactivated. A parent record does not deactivate for one child only. Deactivation applies to the whole record, so it removes every relationship, every group membership, and chat access for every child the parent is connected to, not only the child tied to the reason for deactivation. If this happens by mistake, the fix is to correct the source system and let the parent return to the feed. Group memberships come back automatically, but relationship data does not, so the other child's class rooms need to be re-established through a new data import rather than restored on their own.
  • Only one relationship was removed, without deactivation. This happens with a custody change, or when one child leaves the school but the parent is not deactivated. Today, this does not reliably remove the parent from that child's class rooms right away. The parent may keep posting in those rooms until an admin runs Re-sync all chats, or until an unrelated update happens to correct it. An improvement to this behavior is planned, but for now it should not be treated as something that clears on its own overnight.

Either way, the off-feed log records who was moved to the Inactive role and which memberships were removed, and is the place to check whether a specific family was affected.

Fix and maintain chat membership

Remove a member from a room directly

For an immediate removal that does not wait on the data layer:

  • Step 1: Navigate to Mobile Apps, select Chat, then open the Chats explorer tab.
  • Step 2: Select the room, then choose Show members to open the right panel.
  • Step 3: Hover over the member's name to reveal the three-dot menu.
  • Step 4: Select block, remove from room, or delete the user, as appropriate.

⚠️ Important Note

Removing someone from a dynamically synced room addresses the room only, not the underlying data. If the person still holds the group membership that placed them there, correct that as well. For a genuine departure, the removal belongs in the source system.

Fix a class room that has not updated

If a class room still shows someone who should no longer have access, or is missing someone who should, a district or site admin can run Re-sync all chats.

  • Step 1: Open Chat Admin.
  • Step 2: Select Re-sync all chats.
  • Step 3: Confirm the action in the dialog that appears.
Use Re-sync all chats when Don't use it for
A specific room needs correcting right away, such as the partial family change scenario above. Routine, day-to-day changes. These update on their own.
A relationship was removed without a deactivation and access has not cleared after a few days. A change that just happened moments ago. Allow a normal update cycle first.

⚠️ Important Note

Re-sync all chats rebuilds membership for every room, not only the one room in question, and it can take some time to finish. Use it when something needs to be corrected right away, not as a routine step.

What the year-end reset does

The reset is not automatic, and responsibility is split.

  • Academic Class rooms. Finalsite Support archives the Academic Class groups in Group Manager. The associated chat rooms archive on the next sync, and the integration is re-enabled for the new year. Schedule an End-of-Year service to start this.
  • Manually created rooms. Rooms with no connection to an Academic Class, such as athletics, PTA, and clubs, are archived by district and school administrators in the Chats explorer.

⚠️ Important Note

Archiving is permanent and cannot be undone. Chat history cannot be cleared without archiving the room. If the Archive button does not appear for a room, that room is tied to an Academic Class and Finalsite Support handles it.

Diagnose a membership problem

Work down the chain rather than starting in Chat. The first layer that disagrees is the one at fault.

  • Step 1: Establish whether the person can reach Chat at all. If Chat reports no access, stop here and check the chat role and visibility settings. This is not a roster problem.
  • Step 2: Confirm the constituent record exists, holds the expected role, has a username, and is not duplicated. A record sitting in the Inactive role, or missing entirely, points to deactivation or deletion: see those sections above for what to expect and how quickly it should clear.
  • Step 3: For a missing guardian, open the student's profile and confirm the relationship exists and points the right way.
  • Step 4: Open the Academic Classes group in Group Manager and compare its membership against the source system.
  • Step 5: Confirm every Faculty or Staff member in the group is designated as Admin.
  • Step 6: Compare the group against the chat room. If the group is right and the room is wrong, determine how the room was created. A room built by adding members by group will never update and has to be recreated dynamically.
  • Step 7: If every guardian is missing rather than one, check whether Parents/Guardians is enabled under "Create chat rooms with..." before investigating any relationship.
Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please Sign in to leave a comment if you don't see the comment box below.