Administration troubleshooting
What you saw, why, and what to do about it.
Getting to the screens
A permission message on the import wizard
PTRS's own rule for this screen admits a site director. The screen checks a narrower rule that does not. There is no setting that changes this: run the import as an organisation administrator or a super admin instead.
A permission message on the user screens
Wider navigation lets a regional director and a site director reach every admin screen, and this particular screen then applies a narrower check on top. Here that narrower check is the correct outcome, since managing users really is limited to an organisation administrator and a super admin. Ask one of them.
Every screen says my account is not assigned to an organisation
Your account record is missing, hidden, or has no organisation recorded on it. An account created through the bare sign-in-identity save always ends up here, since that save never sets an organisation at all.
An organisation administrator has to invite you properly, or your record has to be corrected directly. See how a person becomes a PTRS user.
Signed in, no error, and every screen is empty
Reading your own account details failed because no account record's sign-in reference matches your token's own identity. Every screen then has no organisation and no sites to work with, and most of them show their ordinary empty state rather than an error. This is the exact same failure the development sample data has for its own guardian account.
Match the account record's sign-in reference to your real one.
Managing users
The user list is empty on an organisation that has users
The screen's own read has no separate path for an error, so a refused request and a genuinely empty result both show the same "no users found" message.
Check your own role first, then clear your filters. An empty list on a working organisation administrator account with no filters set really does mean the organisation has no users yet.
The count above the table does not match the rows
The total is worked out before a role filter is applied, and the filter itself runs afterward. The rows you can see are correct; the count, the range and the page total all describe the list before filtering. Nothing to fix, trust the rows.
The user list is slow
Roles are fetched from the sign-in service one account at a time, so a full page of results means that many separate requests. If the sign-in service is slow, this screen is too, and a lookup that fails is swallowed silently, showing that account with no roles at all.
"Invitation sent" but the person never received an email
This message appears on any successful response. The password-setup email itself is requested from the sign-in service, not sent by PTRS, and a failure there is recorded and otherwise ignored. Neither of PTRS's own environments configures a mail server for that sign-in service.
Worse, the record of that failure is written in a shape the activity screen can never actually match against, so the failure cannot appear on the one screen that would show it.
Confirm delivery outside PTRS. If it did not arrive, set the password directly through the sign-in service, or configure a mail server for it.
A role I assigned has not taken effect
A role lives inside the token a person's browser is already holding. The assignment itself is saved immediately, and the person's current session keeps using the roles it already had. Unlike a site-access change, nothing needs to be cleared here, because there is nothing PTRS itself remembers about roles to clear.
Have them sign out and back in.
The OCCL auditor role is not in any role list
Multiple layers agree it does not exist. Neither sign-in environment defines it, PTRS's own list of assignable roles omits it, and anything displaying a user's roles filters unrecognised names out. The role filter on the user list omits it too.
There is no fix available in the product today. The one internal setting named for it has nothing calling it in any case.
A message says the account is not synchronised and cannot be changed here
The stored sign-in reference on that account is not a real one, a placeholder from a development copy of PTRS. This check is deliberate: attempting the change anyway would come back as a confusing, unrelated-looking failure instead.
Expected on built-in accounts. Invite a real person instead.
A reactivated user cannot see any sites
Deactivating an account removes every site assignment it had. Reactivating re-enables the sign-in account and marks the record active again, and does not restore those assignments.
Open the account, Location Access, Edit, re-select the sites, and save.
Every entry in the Activity Log says "ACTIVITY"
The specific action taken is recorded in a field the permanent record never actually keeps; only a generic label and a free-text description survive. The screen shows that generic label as each row's own headline.
Read the line underneath instead. The specific action is in the description text the screen shows beneath it.
"Last login" is never shown
This field is declared and never actually filled in from anything. The detail page does not render it at all, so this is invisible unless you call the underlying action directly.
Deactivating my own account is refused
Expected. PTRS specifically compares the account you are changing with your own and refuses if they match, with a message saying so.
Importing
An unexpected failure when I upload a file
Your list of reachable sites is empty, and the save assumes it never will be. Your list is empty when the organisation has no active sites yet, or when you are a site director with no sites assigned to you.
Create at least one site first, or have an administrator assign you one.
My spreadsheet is rejected
The file picker's own accepted-formats list includes an older format PTRS does not actually read. Only two common spreadsheet formats are accepted.
Re-save the file in one of those two formats.
The data landed on the wrong site
The wizard makes you pick a target site and sends it along, and the save that starts the import does not read it. It uses the first of your own reachable sites instead, which for an organisation administrator can be any site in the organisation.
Revert the import while you are still on the results screen, then run it again as an account whose only reachable site is the one you actually want.
Rows I expected to be created came back as Skipped
Two things compound here. The choice that actually ran was fixed at upload, three steps before the Duplicates screen even appears, and that screen's own choice is never sent. And the default choice skips a detected duplicate rather than creating a second record for it, which is the opposite of what its own description says.
Duplicates are matched on: members by first and last name plus date of birth; staff by email; programs by name, start date and site.
If you meant to merge, revert and run the import again, changing the choice on the Duplicates screen before you upload the file rather than after. If you genuinely meant to create a second, separate record, the wizard cannot do that today.
Re-running an attendance file duplicated everything
Attendance, meal-count and incident imports never check for a duplicate at all, and ignore whatever choice you make. Every row is created fresh every time.
Revert the second import.
Guardian or emergency-contact columns did not arrive
These fields are offered, matched and previewed, and the save behind a member import never actually writes any of them. No guardian record is ever created by an import.
Enter them directly on the member's own record. The full list is in what an import writes.
Imported staff have no credentials or background check
The same shape as the guardian columns: six certification and background-check fields offered, none written.
Enter them directly on the Staff screens. This matters for OCCL readiness, since the directory will look complete while the underlying credential record stays empty.
Every attendance row failed with a message about no active staff member
Attendance, meal-count and incident imports each look for the first active staff account at the target site to use as the recorder, and fail the row outright if there is none.
Import or create staff at that site first, and remember the target site is the first of your own reachable sites, not necessarily the one you picked.
A specific child is reported as not found on an attendance import
Children are matched on first and last name alone, without regard to case, taking whichever match comes first in the organisation.
Import members before attendance, and check the spelling. Two children sharing a name will receive each other's records with no warning at all.
An imported incident is not linked to any child
The Incident template offers a child's name and a staff member's name, and the save behind it never writes either. Every imported incident is also recorded at the lowest severity, regardless of what the file actually says.
Link and re-grade each one directly on the incident record afterward.
Dates came in wrong
Every date and time is read in a fixed, US-style order. A file using the day-first order common outside the US produces wrong dates wherever the day is 12 or lower, and fails the row outright otherwise.
Re-save the file with US-style dates and import it again.
The revert did not put everything back
Records the import created are deleted outright, so those are fully undone. Records it merged are restored from a copy that covers fewer fields than the merge itself changed: for a member, address, city, state and postal code are not restored; for a program, description, minimum age, maximum age and end date are not. Staff restores every field it changed.
Nothing automatic exists for this. The full table is in what an import writes.
I left the wizard and cannot revert
A complete history of every import exists, and a finished screen was built to show it with its own revert button, and no page in PTRS ever shows that screen. Revert Import only exists on the wizard's own final step.
There is no fix from any screen. Reverting after leaving the wizard needs the job's own id used directly.
The Updated figure is always 0
Nothing anywhere in PTRS ever assigns a value to this particular count. Use Created, Merged, Failed and Skipped instead, which are all genuine counts.
A message about missing organisation context on every import call
Every import action starts by checking that your account has an organisation. If it does not, you are in the same state covered above.
Profile and password
"Current password is incorrect." when I am sure it is right
Your current password is checked using your email address as the sign-in name. If your sign-in email differs from your PTRS email, or you have never actually set a password because the invitation email never arrived, this is what you will see.
Confirm the email on your PTRS record matches your sign-in account, and that you have set a password at least once.
"Password does not meet complexity requirements."
This is the sign-in service's own rule, not PTRS's. PTRS itself only checks that the password is at least 8 characters and different from the current one.
Changing the theme or the language does nothing
Nothing reads these values back. They are saved by the Preferences tab and read back only by that same tab, and by nothing else anywhere in PTRS.
Turning notifications on switched something else on
Four separate preferences are presented as a single switch. Reading it shows on if any one of the four is actually on; saving it writes your one choice onto all four together.
There is no fix from this screen. It has no real effect either way in any case: PTRS has never sent a notification of any kind, anywhere in the product.
Every user-management screen fails at once
The service PTRS uses to talk to the sign-in system is only available when a specific setting has a value. Nine of the ten user-management actions depend on it, so if that setting is missing, none of them can even start. If the setting is present but a related secret is wrong, the request to the sign-in service fails instead, and the error looks like a problem reaching an outside service rather than a missing setting.
Check that setting and its related values, and that the account behind them holds the right permissions on the sign-in side.
Related
Checked against PTRS on 7 September 2026.