Why My CSV Import Stops Before It Sends Any Shift Emails

I separated shift import from notification sending so a spreadsheet could be reviewed before its mistakes reached the cleaning team.

A CSV upload can finish successfully while still containing the wrong shift.

The file may have the expected columns. Every row may parse. The dates may be recognizable. None of that proves that Maria was assigned to the correct Monday job, that 9:00 AM was entered in the intended local time, or that one client visit was not accidentally compressed into a single row.

That created an important boundary while I was working on shift imports for CleanConfirm:

Importing the schedule and notifying the cleaning team should not be the same action.

A valid row is not necessarily a correct assignment

The import format needs six required values for each shift:

• shift_date
• start_time_local
• end_time_local
• assigned_member_email
• client_name
• address_full

These fields are enough to describe an assigned cleaning shift at a basic level. Optional columns can carry details such as entry instructions, access notes, a contact phone number, or internal notes.

But required fields only establish that the row is complete enough to create something.

They do not answer whether the assignment is operationally correct.

An email address can be formatted correctly but belong to the wrong cleaner. A start time can be valid but entered for the wrong day. An address can be present but omit the unit number or building entrance the cleaner needs.

The importer should not pretend it can resolve every one of those mistakes automatically.

One row needs to mean one shift

A spreadsheet often reflects how the person who created it thinks about the work.

One manager may use one row per client. Another may use one row per cleaner. Someone else may put an entire week into a single cell and use line breaks to separate the visits.

That flexibility is useful when a spreadsheet is only being read by people. It becomes risky when software needs each row to produce a predictable record.

For this import, the narrower rule is one row per shift.

That means two visits to the same client on different days are two rows. Two cleaners working the same site may also require separate assigned-shift records, depending on how the schedule is managed.

The rule is less flexible than a free-form spreadsheet, but it makes the result easier to inspect. A manager can compare one imported row with one created shift instead of guessing how several spreadsheet fragments were combined.

I documented the expected columns and row structure in the CSV import guide for cleaning team shifts, including the distinction between required assignment data and optional job details.

“Imported” should not mean “already communicated”

The dangerous shortcut would be:

1. Upload the file.
2. Create the shifts.
3. Immediately email every assigned cleaner.

It feels efficient because the manager completes everything in one action.

It also turns an internal spreadsheet mistake into an external message before anyone has had a chance to notice it.

A cleaner could receive a shift with the wrong time. An inactive or unintended team member could be referenced by email. A job could be missing the access detail that makes the assignment usable. Correcting the database afterward would not retract the first message or remove the confusion it created.

The safer sequence is deliberately less automatic:

1. Prepare the CSV.
2. Upload it.
3. Review the shifts that were created.
4. Send notifications after the assignments look right.

The review step is not just a nicer confirmation screen. It separates two different commitments.

Creating a shift changes the workspace data. Sending a notification tells another person that the assignment is ready for them to act on.

Those actions should not share the same definition of success.

Some checks belong before upload, others belong to a person

A few problems can be described with clear rules.

Each row should represent one shift. The assigned email should match an active member of the workspace. Start and end values should use recognizable local times such as 9:00 AM or 09:00. The full address should be present when the cleaner needs location context.

Other problems are harder to reduce to validation.

Software cannot always know that the manager selected the wrong Maria, that a familiar client changed locations last week, or that “side entrance” is no longer accurate. Those details can be structurally valid and still be wrong.

For the first version, I would rather make the review boundary obvious than build an importer that appears more intelligent than it is.

Validation can reject a missing value or an unusable format. Review gives the manager a chance to catch a plausible-looking mistake.

Both are useful, but they solve different problems.

Keep the first action reversible

A good import action should move data into a state where it can still be checked without creating unnecessary consequences outside the product.

That does not mean the manager needs to approve every field through a long wizard. It means the upload should stop at a sensible boundary.

The shifts exist. The manager can inspect them. The cleaning team has not yet received a message based on an unchecked spreadsheet.

Only after that review should the workflow cross from internal preparation into communication.

The extra pause may add one action, but it prevents “the CSV uploaded successfully” from being mistaken for “the schedule is ready to send.”