Understanding Your Data
How to read what the platform shows you, and how to tell a real operational signal from a data problem.
Once your data is connected, the most valuable thing you can do is spend an hour convincing yourself it is right. Almost every "the optimization gave me a strange answer" conversation turns out to be a data question.
Postal areas
The platform's geographic unit is the Canadian forward sortation area — the first three characters of a postal code.
- The first character is a province or region (
Mis Toronto,Kis eastern Ontario,Vis British Columbia). - The second character distinguishes urban from rural: a
0means rural. - Areas vary enormously in physical size.
M5Vis a few city blocks; a rural area can be hundreds of square kilometres.
That last point matters more than it sounds. Two regions with the same number of areas can involve wildly different amounts of driving. When you are balancing travel, look at the map, not the count.
Regions
A region is a named group of areas. Where regions come from depends on your source:
- AlayaCare — taken from the groups configured in AlayaCare.
- GoldCare and AxisCare — derived from client postal codes, because those systems do not expose a geographic region concept.
- CSV — whatever is in your region column.
The regions the platform discovers are your source system's idea of your structure, which is not always your operational reality. If your teams actually work to a different set of territories than your scheduling system records, fix that in the Data Editor before you draw any conclusions.
Sanity checks worth doing once
Do the totals match? Add up active clients across all regions and compare it to what your source system reports. A large gap means the area selection is wrong or the source is filtering something out.
Are there areas with a count of one or two? Almost always a mistyped postal code. They create phantom territory and can drag an optimization toward covering places you do not actually serve.
Are any expected areas missing? Either the source is not returning those clients, or their postal codes are not populated.
Do the ratios look plausible? Clients per employee, hours per client. If a region shows 400 clients and 3 employees, you have found either a serious operational problem or a data problem — and it is usually the second.
Does anything read as zero that should not? A metric that is not being captured shows up as a low number, not as a gap. See the coverage guidance in Metrics Reference.
Telling a data problem from an operational problem
| What you see | Data problem if… | Real if… |
|---|---|---|
| One region far heavier than the rest | It contains areas that belong elsewhere, or duplicate rows | The area assignment is correct and the imbalance persists across refreshes |
| A region with almost no employees | Employees are recorded against a head office area rather than where they work | Staff genuinely left and were not replaced |
| Sudden change since last refresh | The sync failed, or the CSV export covered a different period | Something actually changed |
| Very low completion rate in one area | The metric is poorly covered there | Consistent across refreshes and matches what the branch reports |
The general test: does it persist across refreshes, and does it match what the people on the ground say? If not, look at the data first.
Common data quality problems
Employees recorded centrally. If your source records staff against an office address rather than a working area, employee counts concentrate in one area and every balance calculation is wrong. This has to be fixed at source.
Stale postal codes. Clients who moved but whose record was never updated.
Inconsistent region naming. In CSV especially, North and North Region become two regions.
Period mismatch. A CSV that covers a different date range than you think makes trends meaningless. Be consistent about what each upload covers.
Fixing what you find
- Source data problems must be fixed in the source system. Correcting them in the Data Editor changes only what Optimal Workforce holds and will be overwritten by the next sync.
- Region assignment is legitimately yours to change in the Data Editor — that is what it is for.
- Selection problems — wrong areas, wrong metrics — are fixed by re-running the connect wizard.
Then what
Once you trust the data, go and read the baseline on the Caseload Dashboard before changing anything.