Bulk Importing Bell Schedule Exceptions in Singlewire InformaCast: Five Gotchas We Hit Along the Way

If you manage bell schedules in Singlewire InformaCast, you've probably run into the CSV bulk import feature for adding exceptions — holidays, teacher institute days, half days, and the like. It looks simple on paper: download a template, fill in some dates, upload. In practice, we hit five separate snags getting a single schedule update through, each one a little different from the last. Writing them up here in case it saves someone else the trial-and-error.

The goal

We wanted to add four non-instructional days to our existing "Semester 1" bell schedule so the bells stay silent on:

• Labor Day (Sept 7)
• Columbus Day (Oct 12)
• A Teacher Institute day with no students or Veterans Day (Nov 13)
• Thanksgiving break, a full week (Nov 23–27)

Straightforward exceptions to an existing schedule. Here's what actually happened.

Gotcha #1: The template only shows you one exception slot

The downloadable template ships with a single set of exception columns:

exception-000-description, exception-000-endDate, exception-000-ringListName, exception-000-startDate

There's no visual hint that you can have more than one. It turns out you just repeat the same four-field block with an incremented, zero-padded index — exception-001-*, exception-002-*, and so on. Also worth knowing: each exception block has its own start and end date, so a multi-day event like a full week of Thanksgiving break doesn't need five separate entries — one entry with startDate = the Monday and endDate = the Friday covers the whole week.

The four field names within a block are alphabetical, which is a handy way to remember the order if you're building the CSV by hand: description, endDate, ringListName, startDate.

Gotcha #2: "Leave blank" is a real, meaningful state — not a placeholder

Singlewire's own field definitions spell this out, but it's easy to miss on a first pass: for both the weekly entry-XX columns and the exception ringListName field, a blank value doesn't mean "no change" or "skip this" — it means "suppress ringing entirely."

We initially typed a made-up label like "Silence Ringing" into the exception's ringListName field, assuming it was just a description of the desired behavior. It's not — it's a literal lookup. The import tries to resolve whatever you put there to an actual ring list's ID, and if no ring list by that exact name exists in your instance, the whole row fails validation with an error like:

Value must be a UUID. (bellScheduleEntries[5][ringListId])

The fix was simply leaving the field blank, which is both valid and exactly what we wanted (no bells on those days).

Gotcha #3: Figuring out which entry-XX maps to which day of the week

The 21 entry-00 through entry-20 columns represent your weekly ring-list pattern, but the template gives zero indication of which slot maps to which day, or whether the week starts on Sunday or Monday. We confirmed this the safe way — by comparing to the actual "Weekly Ring Lists" UI for our schedule, which showed Monday through Friday, in that order, each with a ring list assigned. Since our schedule runs a 1-week pattern, entry-00 through entry-04 mapped to Monday–Friday, and we later confirmed Saturday and Sunday (entry-05, entry-06) were correctly blank by checking those two dropdowns directly in the UI — both were set to "Select..." (i.e., no ring list), matching what the CSV already had.

Takeaway: if you're not 100% sure of the day-of-week ordering for your instance, check your existing schedule's UI settings before you guess. Getting this wrong silently kills bells on the wrong day.

Gotcha #4: Bulk import creates — it doesn't update

We assumed that submitting a row with the same name as our existing bell schedule would update it in place — adding our new exceptions to the schedule that already existed. Instead we got:

Name Semester 1 has already been taken. (name)

The bulk import tool, at least in the mode we were using, treats name as a unique key for creating new records, not merging into existing ones. There was no update path via this same flow — we ended up deleting the existing bell schedule and re-importing the full definition (weekly entries + exceptions) as a fresh create.

Takeaway: if you're adding exceptions to a schedule that already exists and has live ring list assignments, be prepared to either delete-and-recreate, or check whether your version of InformaCast has a separate update-specific import path. Don't assume "same name" means "merge."

Gotcha #5: A single missing comma silently shifted every column

After fixing gotchas 1–4, one more test import failed — and the CSV looked fine to the eye, but broke when opened in Excel, which flagged a suspicious lack of a trailing comma in the data row. Running the file through a quick CSV parser and counting fields per row confirmed it: the header row had 43 columns, the data row had 42. One missing comma between the last entry-XX field and the first exception field had silently shifted every single value one column to the left — so Labor Day ended up sitting in the entry-20 slot, dates ended up under description fields, and so on.

Takeaway: don't trust "it looks right" when eyeballing a wide CSV in a spreadsheet app. Programmatically count fields per row against the header before every import attempt — a one-line script catches this instantly, and it's the kind of error that's nearly invisible to the naked eye in a 43-column row.

The final, working row

Once all five issues were resolved, the working data row looked like this (line-wrapped here for readability; it's one line in the actual file):

Semester 1,Semester 1 for the school year,2026-08-17,2026-12-18,1,America/Chicago,
Normal Day,Normal Day,Early Release,Normal Day,Normal Day,,,,,,,,,,,,,,,,,
Labor Day,2026-09-07,,2026-09-07,
Columbus Day,2026-10-12,,2026-10-12,
Teacher Institute Day - No School,2026-11-13,,2026-11-13,
Thanksgiving Break,2026-11-27,,2026-11-23

Checklist for next time

• Confirm the exact day-of-week order for entry-XX against your instance's UI before filling anything in — don't assume Sunday-first or Monday-first.
• Leave ringListName blank if you want bells fully silenced — don't invent a descriptive label expecting it to be interpreted rather than looked up.
• Test whether your import is create-only or supports updates before assuming a same-named row will merge into an existing schedule.
• For multi-day exceptions, use one startDate/endDate range instead of one row per day.
• Before every import attempt, programmatically verify every row has the same number of fields as the header. A visual check in Excel is not enough.
• Test on a throwaway/duplicate schedule first if you're not fully sure how your fixes will behave — several of these errors would have been much messier to walk back on a live, in-use bell schedule.

None of these issues were exotic — they were mostly gaps between what the template implies and what the system actually validates. Hopefully this saves someone else a round or two of failed test imports.