Setting Up Department and Branch Hierarchy in HR: The Approval Backbone

Why hierarchy has to come first, not last

Branch and department hierarchy is the structure most HR rollouts save for later — and the one that quietly determines everything else. Companies typically start with employee records and tell themselves they'll "sort out the org chart afterward." But which manager an approval request lands on, who can see whose timesheet, and which team actually receives a given announcement all trace back to how this hierarchy was built. Get it wrong, and the system keeps running — it just keeps routing requests to the wrong people and handing visibility to the wrong managers.

This piece is about designing a hierarchy once, correctly, so nobody has to patch it later.

It's not just an org chart

Most companies treat hierarchy as a documentation exercise — a diagram of who reports to whom. In an HR platform, branch and department structure actually decides three separate things at once:

• Where the approval chain starts. When a leave or expense request is submitted, the system looks up "who is this employee's direct manager" from the hierarchy. Get the hierarchy wrong, and the request either has nowhere to go or lands on the wrong desk.
• The boundaries of visibility. A site manager should only see staff on their own site; a department head should only approve requests from their own department. That boundary is derived from the hierarchy — set it up once and permissions follow automatically instead of being assigned user by user.
• Reporting and announcement targeting. A filter like "send this announcement only to the Istanbul branch" or "scope this report to sales" only works once the underlying hierarchy actually reflects reality.

Hierarchy setup isn't a one-time administrative task — it's the foundation everything else in the system sits on.

Org chart vs. real reporting lines

The most common mistake is copying the official org chart into the system as-is. But the formal chart and who actually reports to whom day to day frequently diverge: a regional manager might sit under the general manager on paper but actually report operationally to a site coordinator; an accounting clerk might be listed under Finance while their expense approvals really run through an operations manager. Build the system around the paper chart, and requests get routed to a role that's technically "correct" while the real decision-maker never sees them — the request gets approved without the actual manager knowing, or it sits waiting because it never reaches the person who should act on it.

The right question before building anything is: when something goes wrong with this employee's work, who actually steps in? The answer to that question, not the box on the chart, is what should drive the setup.

Build order: branch, then department, then employee

In practice, hierarchy is built in three layers, and the order matters:

1. Branches are defined first. Physically or operationally distinct units (the Istanbul office, the Ankara branch, a production site) get set up as branches. In a multi-branch business, each branch has its own approval chain and reporting scope.
2. Departments are placed under each branch. The same department name (say, "Accounting") can repeat across branches; what matters is that every department is clearly tied to one branch.
3. Employees are assigned to departments and given a direct manager. This is the most critical step, since the approval chain starts here. Every employee should have exactly one direct manager — ambiguous or dual-reporting employees are where approval chains stall.

Skip this order — adding employees before departments exist, for instance — and you accumulate "managerless" employees during the transition, whose requests sit with nowhere to go.

Common scenarios in multi-branch setups

A small, single-branch team rarely runs into trouble with a simple hierarchy. As a company grows, three situations come up repeatedly:

• The same employee works across multiple sites. A technician might serve both the Istanbul and Kocaeli branches. In these cases, the employee's primary branch should be clearly defined, with secondary assignments tracked through a separate mechanism (a temporary assignment), otherwise reporting gets confused about which branch the work actually belongs to.
• One site has more than one manager. In shift-based operations, day and night managers may differ. If the hierarchy doesn't account for this, a night-shift employee's request lands on the day manager and sits for hours before anyone notices.
• A new branch opens. As branch count grows, rebuilding hierarchy by hand every time wastes effort. A well-designed structure lets you add a new branch and department without disturbing the approval logic already in place for everyone else — the operational side of opening a new location is something we covered in our guide to launching a new restaurant branch.

What a broken hierarchy actually costs

The impact of a wrong or incomplete hierarchy isn't abstract. An employee with no defined direct manager has a leave request that's invisible to anyone and sits "pending" for days. An employee assigned to the wrong department has an expense request routed to a role with no context to evaluate it. A branch-specific announcement reaches employees at a different branch because the hierarchy was set up incorrectly, creating confusion nobody asked for. None of these are system bugs — the system is doing exactly what the hierarchy tells it to do. The problem sits in the setup, not the software.

Four practical rules for setup

Don't forget delegation. So a request chain doesn't freeze while a department head is on leave, every critical role needs a backup or an automatic escalation rule. When a direct manager is out, the request escalating to the next role up is simply the hierarchy reflecting the real reporting line.

Don't confuse a role with a person. Set it up as "this department's manager role is filled by Ayşe," not "Ayşe manages this department." When staff changes, only the assignment changes — the hierarchy itself stays intact.

Do bulk imports after the hierarchy is built. Importing your existing employee list via CSV works cleanly once branch and department structure is already defined; otherwise you're fixing individual records one by one after the fact.

Review the first month's output. In the weeks after setup, checking which requests are sitting pending and which announcements never reached their target surfaces the connections that looked right on paper but didn't hold up in practice.

The bottom line

Branch and department hierarchy is the invisible backbone of an HR system — the piece nobody notices when it's right and everyone blames the wrong module for when it's wrong. Get it right, and approvals, visibility, and reporting all fall into place on their own; get it wrong, and every module looks broken even though the real issue lives in the foundation underneath all of them. In HR-Tech's field-tracked HR platform, company registration is self-service, and setting up the branch-department-employee hierarchy is the very next step; once that structure is defined correctly, approval flows, permission visibility, and targeted announcements build on top of it automatically. If you'd like help building your hierarchy from scratch or reviewing an existing one, reach out through our contact page.