Field workforce management software fails on structure, not features. Approvals route to the wrong supervisor, and transferred staff keep old store lists because the reporting line, team, and data access are maintained by hand in three places. One org structure that all three inherit from removes the errors permanently.
A leave request sits unactioned for four days. The name on the approval screen belongs to a supervisor who moved to another team in August. Nobody catches it until the employee follows up, and by then the payroll cutoff has passed.
A promoter transfers from a North Luzon cluster to a Metro Manila one. Her team changes in the system that same day. Her assigned stores do not. For the next two weeks her app still lists her old branches, her new supervisor cannot see her attendance, and her old supervisor still sees an employee who no longer reports to him.
Neither of these is a discipline problem. Both are structure problems, and they happen in companies that have already bought good software. The system was told who the employee is. It was never told, in one place, where that employee sits.
The three fields nobody owns
Open the employee record in almost any field operation and you will find three separate settings that decide how the whole system behaves.
The first is the reporting line, usually labelled something like “reports to.” It decides where a leave request, an overtime request, or an expense claim goes for approval. The second is the team. It decides which roster the employee appears on. The third is data access: the list of employees or stores a supervisor is allowed to see.
In most deployments we walk into, all three are maintained by hand. An admin opens a profile, picks a supervisor from a dropdown, then opens a second screen and ticks the teams that person can view. When a cluster gets redrawn, that work repeats for every affected employee. We have seen HR teams doing this weekly, for the same supervisor, because a team changed again.
The failure mode is that nothing breaks loudly. A wrong reporting line does not throw an error. It quietly sends an approval to someone who is no longer responsible. A stale data-access list does not warn anyone. It quietly hides four merchandisers from the report their supervisor uses to plan tomorrow.
Stricter process does not hold this together
The instinct is to fix it with discipline. Write the transfer procedure down. Add a step to the offboarding checklist. Audit the assignments every month.
That works in an office where the structure changes twice a year. Field organisations do not behave that way. Agency-deployed staff rotate. A supervisor covers two areas for one month while a colleague is on leave. Territories get redrawn mid-quarter when a new distributor comes on. A cluster of ten stores becomes fourteen after a mall opens.
Every one of those events requires someone to remember three fields on possibly dozens of records. The structure changes faster than the checklist gets run, and the people best placed to notice the error are the field supervisors, who have no way to see what was assigned to them versus what was assigned below them.
One structure, three inheritances
The version that holds is a single org structure that the rest of the system reads from, rather than three fields kept in sync by goodwill.
Approvals inherit the reporting line. Instead of typing a supervisor’s name into each employee record, you define the workflow by position: the request goes to the team head, then to the group head above that team. When a team head changes, every request in that team reroutes on its own. The person who transfers in on Monday is already routing correctly on Monday, and the request that was in flight does not need to be cancelled and refiled.
Visibility inherits the structure. A supervisor sees the people in the teams beneath them because the structure says those teams are beneath them, not because an admin remembered to tick eleven boxes. This is the setting that most often goes stale, and it is the one with the quietest consequences. A supervisor working from an incomplete roster makes correct decisions on incomplete data, which is worse than an obvious outage because nobody escalates it.
Territory inherits the structure too. Stores, accounts, and routes get assigned to a team or a group rather than to a list of individual names. Add a member to the team, and they inherit the coverage. Move them out, and the coverage leaves with them. This is the connection most systems miss, and it is why a transferred promoter keeps seeing her old branches. Anyone rebuilding coverage plans across a dealer or distributor network will recognize the problem from the ground up, and it is worth reading alongside the basics of distribution management.
Approvals, visibility, and coverage stop being three maintenance jobs and become three consequences of one decision.
Store the grouping, not the list
There is a second structural choice underneath that one, and it decides whether anyone can ever check the work.
Open a supervisor’s assigned stores in a large deployment and you may be looking at several thousand rows. Ask the honest question: if one store were missing from that list, would you know? Nobody can audit five thousand rows. So nobody does, and the list drifts.
Now store the same assignment as the grouping that produced it. This supervisor covers NL Cluster 1. That group head covers all Mindanao stores. That is two lines instead of thousands, and both are checkable in a second by anyone who knows the business. Drill into the group when you need the detail. Read the logic when you need to know whether it is right.
The same principle applies to every store view. Next to each store, show why it is assigned: directly to the employee, or through the employee’s team. Call that field the assignment logic, because that is what the person troubleshooting at five in the afternoon is actually looking for. When a merchandiser reports a store they should not be visiting, the answer to “how did this get here” should take one hover, not a support ticket.
Let access flow upward
The last piece is a default that makes errors visible instead of hiding them.
Set data access to flow upward: a supervisor sees whatever you assigned to them directly, plus everything assigned to anyone below them. Nothing more to configure per person.
The reason for doing this is not convenience. It is detection. Say a team leader is assigned the North Luzon group. Below them sit NL Cluster 1, NL Cluster 2, and, because of a transfer nobody finished, a stray cluster from a different region. On that team leader’s screen, the stray sits in plain view next to the two clusters that belong there. The person with the most context is now the person most likely to see the mistake on a screen they open every day.
Compare that with the alternative, where each level’s access is typed in separately. A wrong assignment three levels down is invisible to everyone above it. It surfaces at month end, when someone reconciles coverage against sales and the numbers refuse to match.
What changes when the structure holds
The payoff is not a tidier admin panel. It is that field data becomes usable while it still matters, instead of arriving late enough to turn insights into hindsights.
Megasoft runs secure attendance and coverage data across 1,500 merchandisers and coordinators on Tarkie. At that headcount, hand-maintained visibility lists are not a chore, they are a permanent source of error. The structure has to carry it.
Chooks-to-Go digitized 90% of their field reports and doubled store coverage from 10 to 20 stores per day per field employee. Coverage gains like that depend on the assignment layer underneath being correct, because a field employee cannot double their store count if their store list is a year out of date.
How to audit your org layer this quarter
None of this needs new software to start. It needs an afternoon and an honest look.
- Pull your five most recent transfers. For each one, check all three fields: reporting line, team, and assigned stores. Count how many of the fifteen are still pointing at the old structure.
- Count the approvals older than three days. Then check whether the named approver still holds that role. This gives you the cost of the reporting line in days of delay.
- Open one supervisor’s store assignment. If it is a flat list longer than a screen, you have no audit trail. Write down the grouping it should be instead, in the words your operations team already uses.
- Name your groupings before you build anything. NL Cluster 1, Mindanao South, Key Accounts Metro Manila. Structure is only checkable when its labels match how people already talk about the territory.
- Assign one owner for the structure. Not for the software, for the structure. Someone whose job includes knowing that today’s org chart matches today’s deployment. Downstream systems like automated shift scheduling all read from this layer, so one wrong team assignment propagates quietly.
- Load it in bulk before you design a screen. Export current assignments to a spreadsheet, correct them there, and upload the corrected version. Getting the data right is a week of work. Designing the perfect interface for maintaining it by hand is a month, and it solves the smaller problem.
What field workforce management software should handle automatically
This is the layer we have spent the most engineering time on in Tarkie, because it is the layer that decides whether everything above it can be trusted.
The org structure holds teams and groups, and the reporting line, team membership, and data access are read from it rather than stored three times. Store assignment attaches to a team or a group, so coverage moves when people move. Every store view carries its assignment logic, so a supervisor can see whether a store reached them through their own assignment or through someone in their team. Access flows upward by default, and the attendance and timekeeping views in Tarkie’s employee productivity suite read the same structure rather than a second list.
One deliberate choice worth naming: when we ship structural changes like this, they arrive switched off. A company that has not mapped its org chart yet should not have its approvals rerouted on a Tuesday morning by an update it did not ask for. You map the structure, you check it against a live team, then you turn it on.
Fix the structure, then buy the features
Field visibility problems usually get diagnosed as reporting problems, so companies go shopping for better dashboards. The dashboard is rarely the constraint. If your org structure is maintained by hand in three places, every report drawn from it inherits the same errors, faster and in nicer colours.
If your approvals are landing with the wrong supervisor or your field teams are working from store lists nobody can audit, we are happy to walk through how your structure would map in Tarkie before you change anything. Book a session at go.tarkie.com/inquire and bring your messiest cluster. That is the one worth testing.
Which of the three fields breaks most often in your operation: the reporting line, the visibility list, or the store assignment?
Frequently asked questions
What should field workforce management software handle automatically?
It should derive the reporting line, team membership, and data access from one org structure instead of storing them as three separate fields on each employee record. Store and territory assignments should attach to teams and groups, so coverage follows people when they transfer. Anything maintained by hand across three screens will drift within weeks in a field operation.
Why do leave and overtime approvals go to the wrong supervisor?
Because the approver is stored as a name typed into each employee record rather than derived from a position in the org structure. When the supervisor changes teams, every record that still names them keeps routing there. Defining the workflow by position, such as team head then group head, makes reassignment automatic.
How should store assignments be structured for large field teams?
Assign the grouping rather than the exploded list of stores. A supervisor recorded as covering NL Cluster 1 or all Mindanao stores is auditable at a glance, while a flat list of several thousand rows is not. Keep the drill-down for detail, but store and display the logic that produced the assignment.
What is bottom-up data access in a field team hierarchy?
Bottom-up access means a supervisor sees what was assigned to them directly plus everything assigned to anyone below them in the structure. It removes per-person configuration and, more usefully, it surfaces errors. A store or cluster assigned to the wrong team appears on the screen of the supervisor most likely to recognize it as wrong.
Should we map our org chart before rolling out digital approvals?
Yes. Approval workflows read from the org structure, so an incomplete or outdated chart routes requests incorrectly from day one. Map the structure, load current assignments in bulk, verify them against one live team, then switch the workflows on for that team before expanding.