Import a file of records
Load a spreadsheet of members, staff, programs, attendance, meal counts or incidents, check what will actually be written before you commit to it, and be able to undo it afterward.
PTRS's own rule for this action admits a site director, and the screen checks a narrower rule that does not. A site director reaching this screen sees a permission message rather than the wizard itself. Use an organisation administrator account instead.
Before you start
Your organisation needs at least one site already, or the very first upload fails outright rather than showing a message. Importing attendance, meal counts or incidents also needs at least one active staff account at the site the data will land on, since all three record types pick a recorder that way and fail every row if none exists. And read what an import writes first: the wizard offers 64 fields, writes 41 of them, and the 23 it discards include every staff credential and every guardian contact.
Steps
1. Select record types and a site
Six cards: Members, Staff, Programs, Attendance, Meal Counts, Incidents. Pick one or more. Opening a card lists that type's fields and offers a template you can download: a two-line file naming the columns and marking which are required.
Above the cards is a site choice, and the wizard will not let you continue without one.
What you choose is sent along with the upload, and the save that receives the upload does not read it. Instead, it uses the first site your own account can reach, which for an organisation administrator can be any site in the whole organisation.
This matters: the site ends up recorded on imported staff, programs, meal records and incidents. Imported members get no site recorded at all, and imported attendance rows carry the child's id and no site.
The only way to control this today is to run the import as an account whose only reachable site is the one you actually want.
2. Upload the file
Drop a spreadsheet file, or browse for one. The screen states its real limits: 50 megabytes, up to 50,000 rows, and both figures are genuine.
The picker also offers an older spreadsheet format that PTRS does not actually accept, which fails with a message naming the two formats it does.
Uploading starts the job, and checking the file then runs on its own and reports back.
| Result | Meaning |
|---|---|
| An error naming no data rows | Nothing after the header |
| An error naming no column headers | The first row is empty |
| An error naming too many rows | Split the file into smaller pieces |
| A warning naming duplicate column headers | Only one of the matching columns can actually be used, since columns are matched by name |
A checking error stops the job outright, and it cannot be continued: start again with a corrected file.
3. Match up the columns
PTRS suggests matches from your own column names automatically, first by an exact match once punctuation and case are ignored, then by a partial match in either direction, including a short list of common abbreviations. You then confirm or change each pairing. Every pairing needs both a source column and a target field, and the same target field can never be used twice.
Saving replaces the whole set of matches, so saving again is always safe.
This screen offers every field PTRS knows about for that record type, including the 23 nothing ever actually writes. A guardian's phone number or a certification's expiry date can be matched here, will show up in the preview, and will still never be saved. The full field-by-field list is in what an import writes.
4. Preview
The preview re-reads the first 20 rows and runs them through your matches, one table per record type.
If a required field was never matched, the preview refuses outright, naming each one. This is the only point where a missing required field is actually caught before the import runs for real.
5. Duplicates: read this screen, then set it aside
This screen offers two choices, described as creating new records for every row, or merging with what already exists.
It changes nothing. The choice that actually runs was already fixed three steps earlier, at the moment you uploaded the file, to the default, and nothing on this later screen ever sends a different value.
And that default skips a detected duplicate rather than creating a new record for it, which is the opposite of what its own description says. So on a normal run: a member matching an existing name and date of birth is skipped, not created. A staff account matching an existing email is skipped. A program matching an existing name, start date and site is skipped. Each one is counted under Skipped, not Created.
The description for the merge choice is accurate on one point: attendance, meal counts and incidents are always created new, because none of the three ever checks for a duplicate at all. Running the same attendance file twice will duplicate every single row.
6. Run it
Execute Import runs the whole file in one request. A progress bar checks in periodically as the engine works through it.
Each row is saved on its own, so one failing row fails alone and is recorded with its own message and row number. A row that fails unexpectedly is caught and recorded rather than stopping the whole import.
The uploaded file itself is removed from the server once the import finishes.
Undoing it
Revert Import appears next to Start New Import on the results screen, and only there. It deletes every row the import created, permanently, and restores merged rows from a copy taken before the merge, one that covers fewer fields than the merge itself changed.
The confirmation describes restoring merged records to their original state. For staff, that is true. For members, four fields are not restored: address, city, state and postal code. For programs, four are not: description, minimum age, maximum age and end date. The full table is in what an import writes.
A complete history of every import for your organisation exists, and a finished screen was built to show it, with its own revert button on each entry, and no page in PTRS ever actually shows that screen. Once you leave the wizard, the only way to undo an import from any screen is gone.
Finish reviewing before you leave.
Common errors
| Message | Cause | Fix |
|---|---|---|
| A permission message as a site director | The screen's own check, not PTRS's own rule | Use an organisation administrator account |
| An unexpected failure on upload | Your account has no reachable site at all | Create a site first, or ask an administrator to assign you one |
| A message naming the two accepted formats | You picked an older spreadsheet format | Re-save as one of the two accepted formats |
| A message saying the job is not in the right state to validate | Checking already failed on this job | Start a new import |
| A message naming missing field matches, doubled in its own wording | Step 3 was skipped, or saving it failed | Return to matching the columns |
| A message naming specific unmatched fields | A required target field has no column matched to it | Match it, or remove that record type |
| A message saying the uploaded file cannot be found | The temporary copy is gone, most often after a server restart between steps | Re-upload |
| A message saying no active staff member was found for a site | Attendance, meal or incident import into a site with no active staff | Import or create staff there first |
| A message naming a specific child as not found | The attendance file names someone not in your organisation, matched on name only | Import members first, and check the spelling |
| A message saying the job was already run | Re-running a completed job | Start a new import |
| A message naming the file size limit | The file is over the size limit | Split the file |
| A message saying your account has no organisation context | Your account is not assigned to an organisation | See Getting started |
Related
Checked against PTRS on 7 September 2026.