Setting up office detection and network configuration for deskbird Dock

Early Beta

Office detection is what tells deskbird Dock which office a device is in. Nothing else works without it: monitor data is only transmitted once a device has matched a recognized office network, so desk detection and every booking automation depend on this configuration. This article covers how to add a network, how the matching logic works, and how to avoid rules that quietly match nothing — or match two offices at once.

1. Add a network to an office
2. How network detection works
3. Ethernet and Wi-Fi support
4. How values are matched
5. Avoiding ambiguous rules

1. Add a network to an office

Office detection is typically configured by the IT team. To link a network to an office:

1. Navigate to Admin > Workplace Intelligence > Presence detection: Office detection
2. Click "Add network"
3. Enter the office and network details (Wi-Fi SSID/BSSID, Default gateway, Subnets, or Public IP) to link them to the office

Once a network is added, users connecting from that network are detected automatically. Devices that are already running pick up the new rule within an hour, or immediately via deskbird Dock > Activity > Sync now. Users are checked in only if check-in is enabled for that office and resource type, and if your privacy mode allows booking automations.

2. How network detection works

Detection combines two levels of logic:

• Between rules (OR): you can add several network rules to the same office. Connecting to any one of them triggers detection and the related automations.
• Within a rule (AND): all conditions enabled inside a single rule must be met at the same time.

This means different connection scenarios — for example Wi-Fi and Ethernet — are best covered by adding a separate rule for each, instead of combining every condition into one rule.

💡 Note: only enabled rules are used for detection and sent to Dock. A rule that has been switched off never matches, with no other symptom.

3. Ethernet and Wi-Fi support

deskbird Dock supports both Ethernet and Wi-Fi connections. Which conditions can be matched depends on the connection type:

⚠️ Note: because SSID and BSSID are not reported over Ethernet, a rule containing either of them only ever matches over Wi-Fi. For offices where users connect via Ethernet, add a rule built on Default gateway (MAC), Subnets (CIDR), or Public IP. To find the gateway value, open the deskbird Dock dashboard while on the office network, look at the Ethernet connection, and copy the "Gateway - MAC" field.

4. How values are matched

• Public IP: matched as an exact address, not as a range — add every address your office egresses from. A rule that uses only a public IP address matches every connection from that address, including VPN or home traffic that shares it. Dock does not observe its own egress address; deskbird verifies it from the connection itself, so after a network change the public IP condition is briefly unavailable and detection over a public-IP rule can take a moment longer on arrival.
• Wi-Fi network names (SSIDs): matched case-sensitively. Gateway MAC addresses and access points (BSSIDs) are not case-sensitive.
• Subnets: matched by containment. The configured subnet must be equal to or wider than the one the device sees — a configured /24 does not match a device on a /16.

💡 Note: offices identified by a public IP alone require deskbird Dock 0.7.0 or later. On earlier builds, a rule containing only a public IP does not match.

⚠️ Important: Wi-Fi conditions also depend on the operating system's location permission. On macOS, and on Windows 11 version 24H2 and later, Dock cannot read the network name or access point without it, so any rule containing SSID or BSSID silently fails to match. See deskbird Dock: overview and setup for the permission steps.

5. Avoiding ambiguous rules

⚠️ Make sure no single connection can match two offices. Values may be shared between offices — a gateway MAC that is identical across sites is fine — as long as every rule also carries a criterion that differs, such as the subnet or public IP.

If one connection matches network rules from two different offices, deskbird cannot tell which office the user is in and skips presence detection for that observation. No warning is shown to admins, and the office looks empty in Workplace Intelligence — so review your rules whenever two offices share a network value.

Because no check-in happens in that case, any desk booking for that day is then released by your no-show policy, exactly as it would be for someone who never turned up.