Users vs SchoolStaff
Many schools have custom fields that they made to store staff data. Some of us even made fields when the teachers table still existed. By now most/all of those fields have been converted to Database Extensions which makes getting the data much easier. If you want to use your custom staff fields within BrightArrow you can do that. However if your data was migrated to a SchoolStaff extension you may want to consider if that is the correct place for it.
Did you refer to the Teachers table in the past tense?
Yes. The teachers table hasn't existed in over 10 years. Around 2011 PowerSchool created the unified teacher record. This meant that we no longer needed to keep a separate record for each teacher who taught in more than 1 building. To do this they split the data into 2 new tables called Users and SchoolStaff.
But I still see Teachers referenced
While the teachers table no longer exists, they also were concerned with people not knowing how to get to the data they needed. To minimize the pain during the transition they created the Teachers view. A view is a glorified query programmed into the database itself. In this case the view called Teachers replaced the table called Teachers and was made to mimic what the table looked like. It still exists today and when you reference something like Teachers.Last_Name you are referencing the view and that view knows that Last_Name comes from the Users table. Work was done on the back end to make it so the old functionality continued as well. That's why any custom screen that references [05] still works. The work is being done in the background to make sure things kept working.
So what was moved to Users and what was moved to SchoolStaff?
The 2 tables represent all the data from Teachers. Since we had to duplicate teachers when they taught in more than one building there was a lot of data that was duplicated even thought the values didn't change. A teacher's name didn't change when they changed buildings, so why were we recording it again? At the same time some data did change when the user changed schools. Preferred Room wouldn't be the same in different buildings, so we'd still need to be able to record some data on a per building basis. Users and SchoolStaff represent those 2 groups of data.
Users: Records exist one time per person. Fields like Last_Name, First_Name, Home_Phone exist here
SchoolStaff: Records exist one time per User per School they have access to. Fields like Status, StaffStatus, SchoolID, the Schedule fields exist here
So when you are looking for the data in the tables you'd look in the Users table if it's the type of data that wouldn't change building to building but SchoolStaff if the data is school specific.
What happened to my custom fields I had made for the Teachers table?
This depends on how those fields were converted. If you manually converted the fields through the UI or through a plugin then you could have moved them to a DataBase Extension (DBx) table that was linked to Users or to one linked to SchoolStaff. However if you allowed PowerSchool to do it automatically then it was moved to a table linked to SchoolStaff. This makes sense since the program wouldn't know what kind of data the field contained so it would need to pick one of the 2 and SchoolStaff is per user per school just like the Teachers table was.
We don't have exact statistics but based on what we've seen probably 95% of schools that have custom staff fields converted them to SchoolStaff either because they did it and didn't know the difference or because PowerSchool auto-converted them that way.
Is there a problem with User data being in SchoolStaff?
Now we get to the crux of this article. Why is BrightArrow concerned about Users vs SchoolStaff? A lot of districts made staff cell phone fields that were then converted to SchoolStaff. This creates a potential data issue.
The SchoolStaff User Field problem
Lets say you have a district with 4 elementary schools, a middle school, and a high school. PowerSchool will also have graduated school and of course people can have access to District Office even though that's not in the schools list. Now lets say you have an art teacher who teaches at all 4 elementary buildings. To do that you add 4 records in the Account Access and Affiliations page which controls which schools the user can see in PowerTeacher. This means your custom SchoolStaff cell phone field will exist 4 times for this user.
Now lets say this teacher comes into their first building of the day and tells someone in the office that they have a new cell phone number. That person looks up their record in PowerSchool and makes the change. Now the school office person thinks they are done and so does the teacher since they told someone. However that office person only saw the copy of that field for their school, the other 3 were never touched. Since the old value was in all 4 fields now we have a conflict.
To get the data to match for all 4 buildings you'd need to change all 4 versions of that field. That's extra work for a single field. If the office person can't get to the other versions of that teacher they can't even do it, the teacher would then have to go to each school office and repeat what they did at the first to get all 4 done.
Same scenario except the custom field is a Users extension instead of SchoolStaff
The teacher walks into the office at the first school and informs someone of the cell phone number change. That person changes it for that teacher's record and submits. Instantly all 4 schools have the new number. 0 people need to redo any of the work that was done the first time. There is only 1 record so there is no data conflict.
That doesn't affect me, I only have 1 school
That's not entirely true. Even single school districts have at least 3 schools that a person can be attached to because District Office and Graduated are automatic. A lot of people add users to every school they need access to in both security screens since it can be confusing when you need to add a school to the Account Access and Affiliations page vs Admin Access and Roles so they do both. The point is just because you only have 1 real school doesn't mean you have only 1 school in PowerSchool and multiple schools means this is still a potential issue.
I can't re-migrate my field so I just have to live with it, right?
Yes, it's true that once a legacy field is migrated it can't be re-migrated. However that doesn't mean you have to live with the problem. You can create your own Users extension with your custom field, export the data out (make sure to include the SchoolStaff.Users_DCID in your export), import the data back in using Data Import Manager and importing it into your Users extension.
OR
You can use our field that we already have and was installed on your server with our plugins. Since this was such a common issue we went ahead and added a Users extension with a cell phone field, a voice toggle, a text toggle, a secondary email field (for non-district emails should you want to track that), and emergency contact fields. If you want we'll even help you get the data over to our field.
Lets say I use the BrightArrow fields, how do I get them in the screens?
We did that too. When you go to a staff record and click on BrightArrow you'll see 3 tabs. The first tab is the phone/email contacts including our custom fields. If you hover over the labels of each of the fields it'll tell you the table.field so you can import into it or export it out if you need to.
What if I only want to use some of the BrightArrow fields? Is it an all or nothing situation?
No, you can pick which fields export to us. The column will be in the export file but it will be blanked out if you've turned off that field in the settings. So if you wanted to use the cell phone field but not the extra email field you could disable the email field and the export will export the field as blank (though the data will still be in the field within PowerSchool for your use).
As of now the basic user export does not include any of the staff emergency contact fields we added. Those were added by request but really for your use only. If there is interest in having those fields also available they'd be added with their own toggle in the settings so you could enable/disable that data being included in the export. Since currently the fields don't even exist the default would be pre-set to disabled for those fields so that you'd have to say you wanted them (opt-in).
What if we decide to leave BrightArrow? What happens to my data?
The data is yours and the fields are yours. Even if you left our service you'd still have the fields for as long as you wanted them so you are at no risk of losing your data by using the fields from our plugin.
I'd like to use some of the fields but putting the data in seems like a lot of work
If you're willing to allow it you can have staff update their own information. Our plugins include a page in both the admin and teacher portals that will allow users to view and/or edit their own data, even if they normally can't access staff data. To do so they'd
- Click on their initials in the upper right corner of PowerSchool / PowerTeacher
- Click on Manage Profile
- Click on My Contact Info
- View (and if you let them edit) their data as it changes
Wait, I saw home_phone, school_phone and email_addr in there, we want to manage those
This isn't a problem. We've given you options to allow users to view their data but not edit, edit only the custom fields (the stock PowerSchool phone/email fields would be view only), or edit all the fields.
- View My Contacts : Allows users to look but don't touch when they go to My Contact Info
- Edit My Custom Contacts : Allows users to look at the values for their record for home_phone, school_phone, email_addr but they can not edit those fields. The custom fields will all be editable by the user.
- Edit My Contacts : Allows users to view and update their own data in all the fields while in the admin portal. The teacher portal will still not be able to edit the home_phone, school_phone, email_addr due to a security violation that occurs when those fields are editable in that portal.
That's nice and all but I have another vendor that uses my current fields and they charge me to make a change
That's OK Yikes! They charge you?!
If you want / need to keep using your SchoolStaff fields even though you may now have determined they should be user fields, that's OK. We will still customize so you can use them. We will, however, have to comma delimit them so a variable number of values can fit in a reliable number of fields. That also means there could be a conflict in the data for the same person across different buildings. But if you're ok with it then so are we. We don't want you to feel pressure to change, only to let you know the options and offer help should you want to fix your setup.
I think I got it but I'm not sure. Can we talk?
Absolutely. Don't feel you need to make a decision if you aren't ready to. We're here to help in any way we can. You can email us and we'll be happy to answer any questions we can.