Let's talk
data-modelling

People who left months ago still showed on the team list

A manager's team screen showed 39 people, five of them deleted months earlier. 75 people across 60 leaders' teams were only half-deleted.

·

A monitor in a warehouse showing the Sazinga Field portal dashboard that a manager opens before checking the team list.

A state head sends you screenshots. His team screen says 39 people. He knows his team is 34. Five of the names on it left the company months ago, and they are still there in his team activity, in the org chart, and in the sales figures rolled up to him.

We reproduced it exactly: 39 on the screen, five of them deleted. Then we measured how far it went. Seventy-five employees, deleted in six batches between April and August 2025, were only half-deleted, and sixty leaders above them were looking at teams that included ghosts. Fifty-two of the 75 were still flagged as logged in.

What was actually going on

Each employee in the ordering app Aries Agro runs for its field staff is held in two records: a user account and an employee record. Deleting a person wrote the deleted flag on the account and never touched the employee record.

That would be harmless if everything read the account. Nothing does. About thirty queries across twelve services build the reporting tree, and every one filters on the employee record. So the account said gone, and every report that mattered said present.

The fault had already stopped. All 133 deletions since August 2025 wrote both records, so this was old damage, not a live leak. We checked all 75 against the client’s own employee list of 884 rows: none of them was on it, so all 75 were genuinely gone and nothing needed restoring.

There was a second fault in the same function. A field name was misspelt, and the database layer silently dropped the value instead of complaining, which is why 52 of the 75 still showed as logged in.

What we changed

The deletion now completes both records in one step or neither. A repair script fixed the 75, applied to the test system and then production, and verified at both: 75 half-deleted became none, and the live headcount stayed at 1,228, so nothing was orphaned. The state head’s team went from 39 to 34.

The shared code that walks the reporting tree now checks both flags, and five copies of the same tree query in the team activity feed were collapsed into one. At the time of the log entry the data repair was live and the code change, which only prevents a recurrence, was not yet deployed.

What it did not fix

We found other faults in the people data and left them for the client to decide. Six sales-designation accounts are missing from the client’s list, 129 back-office accounts sit inside the sales tree, 22 accounts are inactive but not deleted, two live employees report to a deleted leader, and 221 employees have no manager at all.

The pattern, for anyone whose system says someone left

If your software records a person in two places, check that removing them removes them from both. Then pick a leaver from a few months ago and count your own team screen against the names you know. Five ghosts on a screen of 39 is easy to miss and expensive once it reaches a sales figure.

Where this ends up

Sazinga Field keeps the reporting tree honest when people leave, because every screen that adds up a team depends on it being right.

This came out of building Sazinga Field

Orders, stock, dispatch and the people on the road, in one place. The problem above is one we met while building it, and what we did about it is in the product.

If you run something like this, there is one thing you can do without a call: send one day's order sheet.