This article explains the methods Teramind uses to classify an employee's work sessions as “In-Office” or “Out-of-Office” and how this information is presented in various reports and dashboards.

An employee’s work session is classified as in-office when their computer can be associated with one of your configured Office Locations. Otherwise, the session is treated as out-of-office.

You can use this feature to compare in‑office and remote productivity, measure how much time is spent at each office, analyze hybrid work patterns, and support security and compliance use cases such as enforcing location‑based access policies and maintaining audit trails of where sensitive work was performed.

To assign employees to offices, you must first create office locations. You can do so from the Configurations > Locations screen.

For each location, select a point on the map or use the Latitude and Longitude fields to enter them manually. Use the Radius field to specify a circular area (centered around the latitude and longitude) you want to treat as part of that office.

Optionally, you can associate each location with network identifiers by adding one or more Access Points when creating or editing a location. For each access point, you can add its Wi-Fi SSID, MAC Address, internal network ranges expressed in CIDR Network Range notation, and Public IP Address (TBA - not supported yet) that represent your office’s external internet presence.

Teramind uses a combined approach of geolocation and network data, with network data often supplementing or overriding geolocation for greater reliability.

When geolocation is enabled on the endpoint, the device periodically reports its approximate position along with an accuracy radius describing how confident the operating system is about that position. A smaller radius means a more precise location; a large radius indicates greater uncertainty.

Teramind compares this information with your office areas.

Teramind uses the Radius defined in the location setting (maximum 1,000 meters) and compares it with the device telemetry. In Legacy, if the location is beyond this range, the location is ignored or treated as too imprecise to support an “In-office” decision.

An employee is counted as in an office when at least 50% of their location area overlaps the office’s area on the map. If two offices overlap, Teramind selects the office that is the best fit and closest to the device. If no office overlaps enough, the time is considered out of office. It provides more accurate and robust behavior, especially in areas with noisy GPS. If you see the same coordinates resolve to an office in one row and “Out-of-office” in another, see the Split Logic (Same Coordinates, Different Office Status) section below for why.

To improve reliability, especially when geolocation is missing or imprecise, Teramind also examines the network the device is using and tries to match it to your configured offices.

You can associate an office with the following Access Points in order of precision/priority:

When a device connects to a network, Teramind classifies that session as occurring in that office. It will use the above priority if multiple detection methods are available.

Once a location is detected, it is surfaced in BI reports/dashboards through three primary dimensions/columns:

Sometimes, you might see the same coordinates resolve to an office in one row of the Geolocations report, then show as “Out-of-office” a little later for the same employee. Here is an example:

The 11:52 and 11:21 rows (yellow) report identical coordinates and the same 1,500 m error radius, yet resolve differently. Neither can qualify on its own. The difference is what else sits in each one's 15-minute window: the 11:21 row shares its window with the precise, qualifying 11:16 reading (blue) and displays that result, while the 11:52 row shares its window only with the 11:57 reading (blue), which is clearly out of the office and establishes nothing, so there is no office record for 11:52 to display.

Here is the same four readings from the system's point of view:

Neither 11:52 nor 11:21 can qualify on its own - what each one shows depends entirely on what else is in its bucket.

The same symptom (identical coordinates resolving to different Office values) can also show up for a completely different reason. Here's an example:

The 10:29 and 11:00 rows report the exact same coordinates and the exact same error radius, yet one says "Ridgefield Office" and the other says "Out-of-office". Unlike the previous section, there is no later conflicting reading that overrode anything.

The overlap rule from Method 1 is measured against the employee's uncertainty circle. When the error radius reported by the device is larger than the office's configured radius, the office can never cover 50% of the employee's circle, no matter how close the reported coordinates are to the office center. A 1,500 m error radius against a 1,000 m office tops out at roughly 44% overlap.

So neither the 10:29 row nor the 11:00 row qualified for Ridgefield Office by itself. On their own inputs they are identical, and identically insufficient. A reading like this never marks its 15-minute bucket with an office; it can only display an office that some other reading has already established for that bucket. That is where the two rows part ways.

Look at the 10:09:17 reading. It has a tight 55 m error radius, qualifies for Ridgefield Office, and lasts 19 minutes and 59 seconds, which means it runs until exactly 10:29:16 and stretches across both the 10:00-10:15 and the 10:15-10:30 buckets. Both of those 15-minute buckets are therefore assigned to the Ridgefield Office.

The 10:29:16 reading falls inside the 10:15-10:30 bucket. Since results are resolved per bucket, it inherits the office that the precise reading already established there. That is the only reason it shows "Ridgefield Office".

The 11:00:41 reading has no such neighbor. No qualifying reading lands in its bucket, so there is no office on record to display, and with its own GPS match impossible and no network match available either, the bucket falls through to "Out-of-office". The same happens to every later reading with the same coarse 1,500 m position.

In other words: the employee didn't move at 11:00. The device simply stopped producing precise GPS readings after 10:29, and the coarse readings that remained were never capable of matching the office by themselves.

For reliable in-office versus out-of-office classification, it is important to address known edge cases through proper configuration: