Location Mapping Rules

Location mapping rules tell Pult how to assign WiFi clients to presence locations. Each rule defines conditions (IP subnet, and optionally access point labels) that, when matched, attribute the WiFi activity to a specific location.

How Mapping Rules Work

When Pult receives WiFi client data during a sync, it evaluates each client against the configured rules:

1. Subnet matching: The client's IP address is checked against the subnet(s) defined in each rule. This is the primary matching criterion.
2. Label matching (optional): If the rule includes access point labels, the client's connected access point must also match the label conditions.
3. Priority: When multiple rules match, the rule with the highest priority wins.

If a client matches a rule, its activity is attributed to the rule's target presence location.

Configuring Rules

Navigate to Settings → Presence → General Settings in the Pult Dashboard. The Location Mappings section lets you create and manage rules.

Each rule has:

Subnet Conditions

Every rule must include at least one IPv4 subnet (in CIDR notation, e.g., 10.0.1.0/24). The WiFi client's IP address must fall within one of the specified subnets for the rule to match.

Access Point Label Conditions

Optionally, you can refine rules using access point labels -- tags assigned to your WiFi access points during the AP sync. Two types of label conditions are available:

• Strong labels (AND logic): All specified labels must be present on the access point. Use this when you need to match APs that belong to a specific combination of categories.
• Weak labels (OR logic): At least one of the specified labels must be present. Written as any("namespace:label") in the UI's rule input. Use this for broader matching across multiple AP groups.

Rule Syntax

A rule appears in the UI as a comma-separated list of conditions. The rule matches a WiFi client only when every condition holds.

• Subnet conditions -- quoted CIDR strings, e.g. "10.0.0.0/24". When a rule lists multiple subnets, they are OR'd: the client's IP must fall into at least one of them.
• AP label condition -- any("namespace:label-name", ...). The client's connected access point must carry at least one of the listed labels. If any(...) lists only one label, that label is effectively required.
• The subnet condition and the any(...) condition are AND'd: a client matches only when its IP is in one of the subnets and its access point carries one of the labels.

Label refs are namespaced. The namespace identifies the WiFi provider's grouping -- for example, meraki-network: for a Cisco Meraki network, or aruba-building: / aruba-floor: for Aruba Central.

Priority

When a WiFi client matches multiple rules, the rule with the higher priority value takes precedence. Use priority to handle overlapping subnets or to define fallback rules.

Common Patterns

Each example below is exactly what you would type into the UI's rule input box for one presence location. The "what matches" line spells out the OR/AND semantics so you can trace what each rule fires on.

Subnet only

The simplest case -- a small office with its own unique subnet range, no label needed:

"10.0.1.0/24"

→ Hamburg HQ. Matches any WiFi client whose IP falls in 10.0.1.0/24. No access point label check.

Subnet + AP label

Pin the location to a specific Meraki network so the rule cannot accidentally match clients on overlapping subnets in other sites:

"10.0.2.0/24", any("meraki-network:ChicagoOffice")

→ Chicago Office. Matches when the client's IP is in 10.0.2.0/24 and its access point belongs to the ChicagoOffice Meraki network. Because any(...) lists only one label, that label is effectively required.

Multiple subnets, one location

When a single office spans several VLANs, list each subnet in the same rule:

"10.1.2.0/23", "172.16.3.0/24", any("meraki-network:NewYorkOffice")

→ New York Office. Matches when the client's IP is in 10.1.2.0/23 or 172.16.3.0/24 (either one is enough), and its access point belongs to the NewYorkOffice Meraki network.

Same city, two locations

Two rules, one per site. Their subnets are entirely separate, but the AP label gives an extra guarantee that traffic from one site cannot leak into the other:

"192.168.128.0/24", any("meraki-network:LAStudio")

→ Los Angeles Studio. Matches when the IP is in 192.168.128.0/24 and the access point is on the LAStudio network.

"10.2.16.0/22", "10.2.24.0/22", any("meraki-network:LAMain")

→ Los Angeles Main. Matches when the IP is in 10.2.16.0/22 or 10.2.24.0/22 and the access point is on the LAMain network. Either rule fires for the right traffic, never both.

Identical subnets, different sites

A common case for small branch offices that all ship with the same default LAN range (192.168.1.0/24, 10.0.0.0/24, ...). The subnet alone is ambiguous; the AP label is what makes each rule unique:

"192.168.1.0/24", any("meraki-network:BerlinOffice")

→ Berlin Office. Matches when the IP is in 192.168.1.0/24 and the access point is on the BerlinOffice network.

"192.168.1.0/24", any("meraki-network:MunichOffice")

→ Munich Office. Same subnet, but only fires when the access point is on the MunichOffice network. Without the label, both rules would match every client in 192.168.1.0/24.

Access Point Labels

Whether AP labels are available -- and what their namespaces look like -- depends on your WiFi provider. See the integration overview for details:

• Cisco Meraki -- each Meraki network is exposed as a flat label under the meraki-network: namespace.
• Aruba Central -- buildings and floors from VisualRF are exposed under the aruba-building: and aruba-floor: namespaces. If VisualRF is not configured, no AP labels are available.
• UniFi -- AP label groupings are not exposed. Location matching has to rely on subnets alone.