Build a shift-status key people can actually read

A roster cell might say D, NS, RDO, FBI or AL. The planner may know exactly what each one means, while a new site administrator or worker does not. A shift-status key makes the intended interpretation visible before the roster is published, especially when different projects inherit different spreadsheets.

Start with the actual cell values

Export a list of distinct status values from the source workbook. Include different spellings and abbreviations rather than assuming Day, Dayshift and D are automatically the same. Note blank cells separately: a blank might mean “not rostered”, “not entered yet” or a formula with no saved result. Those are not equivalent operational statements.

Ask the roster owner to define each status. A useful key records the raw value, its intended display meaning, which team owns it and any exception. For a fictional site it could look like this:

Cell value	Meaning confirmed by roster owner	Check before release
NS	Night shift	Does it apply to the intended date?
RDO	Rostered day off	Is the day correctly inside the swing?
FBI	Flight in	Does the source date refer to travel or site arrival?
AL	Annual leave	Is it appropriate to publish this category to workers?

These sample meanings illustrate a review process, not a universal code dictionary. A real organisation may use different codes or policies. Payroll treatment, fatigue rules and site access cannot be inferred from the abbreviation.

Handle what the importer does not recognise

RosterField recognises common aliases and surfaces unfamiliar values during review. The mapping field starts with the cleaned source text, including its case, rather than an empty replacement. Inspect the source coordinate, ask what it means, then confirm the retained label or supply a meaningful mapping. Never invent a shift merely to clear an action.

A blank mapping retains the source value. It is not an instruction to skip or redact the cell. To intentionally remove a value, apply a blank source-cell correction or change the workbook, then refresh the preview. Corrections do not rewrite the stored original upload. Time-only cells and labels exceeding 120 characters require correction before publication rather than silent conversion or truncation.

After changing or confirming values, refresh the preview and compare total entries and known source assignments. The collapsible table contains only the first 100 sample entries in 10-row pages. Retaining a label avoids an unmapped-value omission, but does not establish that the label is correct or safe to share. Check for private notes before confirming.

Keep the key beside the workbook

Document codes as part of the roster-export routine. When a new contractor, project or planner introduces a status, update the key and test a fictional workbook before its first live publication. Avoid relying on cell colour alone; CSV exports and worker views carry text, not every visual convention in Excel.

A published roster tells a worker what was released for the project, not whether a shift has been paid, authorised under an award or safe under a fatigue policy. Keep those checks in the systems and procedures responsible for them.

See the Australian date guide for another source of plausible-looking but incorrect entries, and the upload checklist for a final release sequence.

Questions people ask

Can the app infer what a new abbreviation means?

No. Unknown values are surfaced for review rather than assigned an invented meaning. Ask the roster owner, correct or map the value as the workflow permits, and inspect the updated preview.

Is colour coding enough when exporting a CSV?

No. CSV carries text values, not Excel cell colours. Put an unambiguous status in the source cell, document its meaning for your team and check how it appears in the worker view.