Field Manager Permissions: Setting Up Site-Based Access

Why field manager permissions deserve their own setup

In a company with several construction sites, warehouses, stores or client locations, the word "manager" does not mean one thing. One person is a team's manager on the org chart. Another never appears on the chart but is responsible for what actually happens at a particular site every day. Field manager permissions are about defining that second role properly and showing that person only the data of the people working at the sites they are responsible for.

It can go wrong in two directions. Grant too much, and a site lead sees timesheets, leave requests and personnel files from other sites. Grant too little, and the person who is genuinely responsible for the site never learns that someone stepped outside the boundary or that tracking dropped; the alert goes to a desk-bound manager and arrives late. This article walks through how to find the balance.

A team manager is not a site manager

Separating these two concepts is half the setup.

• A team manager comes from the reporting line in your hierarchy. Leave and advance approvals follow that line.
• A site manager is an operational responsibility tied to a site. They follow the daily status of everyone assigned to that site, whichever team those people belong to.

Three departments can work at the same site while none of their direct managers is on location. Building role-based approval routes solves the reporting question, but it does not answer who should see what on site. That needs a second permission layer attached to the site itself.

HR-Tech models it like this: site manager is a special permission that can be granted regardless of role. The holder counts as the manager of everyone assigned to that site and receives that site's violation and tracking-outage alerts. A site can have more than one site manager.

Sites, not regions: where is the access boundary drawn?

A common question is whether access should be built on a broad unit such as a "region" or on individual sites. The product works site by site: a person's access is defined by the set of sites they are assigned to manage. If you want a regional lead to see five sites, you assign them as site manager of all five.

That approach has two practical benefits:

• Clarity. The boundary of the permission matches real sites drawn on the map. The answer to "which staff can this person see?" is simply the list of sites they manage.
• Flexibility. When responsibilities change and a site moves to another lead, you update that site's manager assignment without rebuilding the org chart.

The honest downside: for a company with many sites, assigning a regional lead to every site one by one takes time during the first setup. We suggest grouping your sites by region first and preparing an assignment table before you start.

Setup steps

1. Pin down your sites and their boundaries

Permissions are only as good as your site definitions. With overlapping or vague sites, "who is responsible for whom" becomes vague too. Define sites on the map following the approach in our guide to defining geofenced site boundaries; a single site can consist of several separate areas and is still managed as one site record.

2. Assign staff to sites

The list a site manager sees is made of the staff assigned to that site. If assignments are stale, the permission produces wrong results: an employee moved to another site keeps showing up for the old manager. If you load people through a bulk CSV import, checking site assignments in the same pass is the cheapest fix.

3. Name the site managers

We recommend at least two site managers per site. A single holder means violation alerts reach nobody while that person is on leave or sick. Since a site can have several managers, this costs nothing extra beyond picking a second name.

4. Write down what the permission covers

The manager role sees their own team and the sites they manage, approves leave and requests, defines and assigns shifts, assigns staff to sites and publishes targeted announcements. Sensitive personnel fields such as identity and financial data are out of the manager's scope and remain with the company administrator. Telling employees and site managers about this boundary up front prevents "why can't I see this?" conversations later.

Which alerts does a site manager receive?

The visible cost of the permission is the alerts. When someone steps outside the site during working hours, every site manager of that site and the person's own HR manager are notified immediately, and the employee gets a reminder to return. A phone that shuts down or has its location permission revoked is also noticed within minutes. We covered how tracking interruptions are detected in a separate article.

The setup consequence is that alerts come with the permission. Making someone a site manager also makes them accountable for that site's violation alerts. So do not pad the list "just so they are informed"; pick people who can actually step in. Otherwise alerts turn into noise and lose their weight.

Common mistakes

Granting access by job title. "Directors see everything" is quick to set up and does not scale. Tie access to the sites a person is responsible for, not to their title.

Assigning once and forgetting. Sites change hands and people leave. Reviewing the site manager list every quarter prevents a former manager from still receiving alerts. Adding this step to your offboarding checklist is the most reliable way to keep it current.

Exposing sensitive data to site managers. Operational visibility and financial visibility are different things. A site manager does not need to see payslips or identity details.

Not recording permission changes. Who granted or removed a permission, and when, should be traceable. We covered this in why audit logs matter.

A short checklist

• Are boundaries and assigned staff up to date for every site?
• Does each site have at least two site managers?
• Do site managers see only operational data, with sensitive personnel fields closed?
• Have departing or reassigned managers been removed from the list?
• Are the people receiving alerts the people who can actually respond?

Wrapping up

Site-based permissions are the middle path between "everyone sees everything" and "nobody can see anything." Set up well, the person responsible on location gets the information and alerts they need, everything else stays private, and every permission change is traceable.

You can see how HR-Tech handles field manager permissions and out-of-site alerts, and if you would like to plan a permission structure that fits your sites, get in touch and we will go through it together.