Setting up office detection and network configuration for deskbird Dock

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 Resource detection and every booking automation depend on this configuration. Each office has its own set of detection rules, a guided setup suggests the right signals for your network, and deskbird checks rules across all offices so conflicts are flagged instead of failing silently. This article covers how to add a rule, how the matching logic works, and how to avoid rules that match nothing or match two offices at once.

📅 Technical support: for questions about deskbird Dock setup and configuration, book a session with our Dock technical expert. These sessions cover deskbird Dock setup and technical questions only. For anything else, please contact deskbird support. Available in English, French and Arabic.

1. Add a detection rule to an office
2. Guided setup
3. Manual setup
4. How network detection works
5. Ethernet and Wi-Fi support
6. How values are matched
7. Avoiding conflicts between offices
8. Export detection rules

1. Add a detection rule to an office

Office detection is typically configured by the IT team. Rules are set up per office:

1. Navigate to Admin > deskbird Intelligence > Office detection
2. Select the office in the office selector at the top right
3. Add a new rule. The Add new rule dialog opens with the guided setup. To skip the questions and enter the signals yourself, click Set up manually.

Once a rule is saved, 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.

💡 Note: Admin > deskbird Intelligence > Setup guide shows your overall deskbird Dock setup progress, including how many networks are configured and whether any conflicts exist.

2. Guided setup

The guided setup is step 1 of 2 in the Add new rule dialog. It asks a couple of questions about how the office connects, and the Suggested setup panel on the right shows which signals will be used for detection based on your answers. If you are unsure about an answer, your IT team will know.

• Public IP range: what kind of public IP does this office have? For example Dynamic, Static, shared across offices, or I'm not sure.
• Subnet: is this office's subnet unique? Choose Yes, office-specific (for example Munich 10.12.0.0/16, Berlin 10.13.0.0/16), No, shared or a default (the same range at every site), or I'm not sure, in which case a safe option is picked that you can confirm with IT later.

To change an answer, click Edit response. When the suggestion looks right, click Use this setup to continue to step 2, where you name the rule and enter the values for the suggested signals.

💡 Note: if you don't know the office's public IP type, the guided setup suggests a Gateway MAC (router address) rule. This gets basic detection working, and deskbird support can help you find the most reliable setup for your network.

3. Manual setup

Manual setup gives IT teams direct control over the rule. It is step 2 of 2 in the Add new rule dialog, reached either via Use this setup or directly via Set up manually.

1. Enter a Rule name, a friendly name so you can recognize the rule later (for example "Munich HQ Wi-Fi")
2. Under Signals, click Add next to each signal you want to use, and enter its values
3. Click Save

The following signals are available:

💡 Note: use as few signals as needed. Every signal you add must match, so two reliable signals work better than five weak ones.

4. How network detection works

Detection combines three levels of logic:

• Between rules (OR): an office can have several detection rules. People count as being in the office when they match any one of them.
• Within a rule (AND): a rule is matched when the device is connected to all of its defined signals.
• Within a signal (any value): several values for the same signal, such as two Gateway MACs for a failover pair, are alternatives. The device needs to match one of them.

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 signal 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.

5. Ethernet and Wi-Fi support

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

⚠️ Note: a rule containing Wi-Fi only ever matches over Wi-Fi, and a rule containing Gateway MAC only ever matches over Ethernet. For offices where users connect both ways, add one rule for each connection type. 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.

6. How values are matched

• Public IP range: enter either a single address or a range in CIDR notation, and add every address or range your office egresses from. A rule that uses only a public IP 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 signal is briefly unavailable and detection over a public-IP rule can take a moment longer on arrival.
• Wi-Fi network names: matched case-sensitively. Gateway MAC addresses and access points are not case-sensitive.
• Subnet: 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 signals 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 Wi-Fi silently fails to match. See deskbird Dock: Overview & Setup for the permission steps.

7. Avoiding conflicts between offices

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

deskbird validates rules across all offices. If rules from two different offices can match the same connection, a conflict warning is shown in the admin interface so it can be fixed right away. The number of conflicts is also shown under Networks configured in Admin > deskbird Intelligence > Setup guide.

Until a conflict is resolved, deskbird cannot tell which office the user is in and skips detection for that connection. Because no check-in happens, 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, and the office shows no presence in deskbird Intelligence.

8. Export detection rules

To review your setup, share it with IT or check for conflicts across many offices, export the detection rules as a CSV file instead of copying them office by office.

1. Navigate to Admin > deskbird Intelligence > Office detection
2. Click Export CSV next to Add rule
3. In the Export detection rules dialog, choose the rules to include: only the office selected at the top right, or All offices
4. Click Export

The CSV file contains one entry per rule with the office name, rule name, public IP addresses and ranges, gateway IPs, gateway MAC addresses, subnets, Wi-Fi network names (SSIDs), access points (BSSIDs), conflicts and creation date. The file name includes the export date.

💡 Note: to pull detection rules into your own tools automatically, use the Public API endpoint Lists company network configurations. It returns the rules with their conflicts and can be filtered by office. See Public API for how to create an API key.