Skip to content

Import basics / Field notes

Map transposed roster fields using physical spreadsheet columns

In a transposed matrix, worker identity follows the physical source column when a missing ID is assigned. Do not confuse that upload-local identity with a shift-list employee ID.

Dates down rows and workers across columns are traced to physical spreadsheet coordinates during field mapping
Original illustrative diagram; no employee records or customer rosters shown.

A fictional facilities workbook places dates down the left side and workers across the top. Each worker’s daily statuses run down a column. This transposed layout is readable in Excel, but it can confuse an administrator expecting one worker per row.

The key is to follow the physical spreadsheet axes, not the order of records in the normalized preview. Field mapping must connect names, identifiers and date cells to the actual source layout.

Recognise the layout before mapping

A conventional matrix has workers down rows and dates across columns. A transposed matrix reverses that arrangement: workers across columns, dates down rows. Both differ from a shift list, where each row represents a shift or roster entry with its own fields.

Open the selected worksheet and locate the date axis, worker headings and status area. Note whether employer, role or location information sits in additional header rows. Do not mistake a repeated heading or instructions block for a worker.

For XLSX, confirm worksheet selection first. Mapping the wrong sheet accurately still imports the wrong source. CSV has one flat table but can retain a transposed arrangement.

Understand generated physical identities

When a matrix is missing worker IDs, the importer can assign physical identifiers within the upload: ROW-# for worker rows or COL-letter for worker columns.

In a transposed matrix, COL-D refers to physical spreadsheet column D. It does not mean the fourth normalized worker, the fourth visible sample row or a company’s permanent employee number.

Skipped columns and non-worker headings do not turn physical coordinates into a consecutive worker list. If columns B and D hold workers while C holds a note, a generated identity based on D still refers to D.

Trace each unfamiliar generated identity back to its source heading before approving the mapping. This is a source-location aid, not an identity verification service.

Do not transfer that rule to shift lists

Shift lists need employee IDs. A matrix’s ability to assign a physical row or column identity does not make identifiers optional in a list of separate entries.

The distinction matters when a workbook is restructured. Converting worker columns into repeated shift rows changes the layout and its identity requirements. Do not paste COL-D into a shift-list ID field just because it appeared during an earlier matrix upload.

Likewise, workers are separate per upload and are not merged across files. A physical identifier within one upload is not a cross-file matching contract. If columns move between workbook versions, do not assume an unchanged generated label identifies the same person.

Test mapping with a source-coordinate walkthrough

Use two fictional workers and three known dates:

  1. Locate each worker’s physical column and heading.
  2. Identify the date cells down the date axis.
  3. Choose the review’s field mapping for that structure.
  4. Refresh the preview after mapping changes.
  5. Compare each visible worker/date/status combination with its original intersection.
  6. Check counts and issue information against the intended source area.

Include a non-worker column in your inspection so you can detect accidental inclusion. If both workers show the same copied heading or dates shift by one row, resolve the structural decision before changing individual status cells.

The upload checklist supplies broader preparation steps. The literal correction guide explains targeted edits once you have established the correct coordinates.

Account for the bounded preview

The normalized sample shows the first 100 rows, ten per page. It no longer resembles the original transposed grid, and it is not full-roster browsing.

Absence from a sample page does not prove a worker column was skipped. Reconcile counts and reported issues with the source. Conversely, seeing one correct normalized row is not proof that every date under that worker column mapped correctly.

Check date interpretation and any unfamiliar status labels as separate decisions. A good structural mapping can still reveal time-only or overlong statuses that need resolution.

Rehearse without real personnel data

Build a small synthetic transposed sheet for the demo and deliberately leave one matrix worker ID absent. Compare the resulting physical identity with the actual column letter.

Use the exercise to learn the mapping behaviour, not to create permanent worker identifiers. The demo cannot publish; a real release requires a signed-in project and a final refreshed review of the intended source.