How to Build a Branch Office Network Inventory

A branch office network is small enough to feel manageable and distributed enough to become hard to support. The router may be known to the network team, while the switch belongs to a local technician, the circuit details sit in a carrier portal, and the subnet plan lives in a spreadsheet. When a site loses connectivity or needs a new device, the first task is often figuring out which record is current.

A useful branch inventory connects each location to the equipment, address space, circuits, and people needed to operate it. You do not need to collect every possible detail on day one. Start with the facts that let someone identify the site, understand how it connects, find the responsible owner, and make a safe change. This guide lays out that model, a practical rollout, and a way to keep it from becoming another stale document.

Decide what the inventory is for

An inventory should answer operational questions, not simply accumulate fields. Before choosing a platform or spreadsheet layout, write down the decisions the records must support. A service desk may need a branch address, local contact, and circuit reference. A network engineer may need the firewall interface, VLAN, gateway, and upstream path. A procurement team may need the carrier, contract identifier, bandwidth, and renewal date.

Choose a small set of first questions such as these:

• Which locations use a particular carrier or circuit type?
• Which device provides routing, firewalling, switching, or wireless at a branch?
• Which subnet and VLAN serve users, voice, guest access, or management?
• Who owns a record and who can confirm it during an incident?
• What changed before a branch stopped reaching a shared service?

The answers shape the first version of the data model. Keep live monitoring, configuration backup, and inventory distinct. An inventory describes intended and known relationships. Monitoring reports current signals such as loss or latency. Configuration management stores device settings. A branch inventory can link to those systems, but it should not imply that a documented circuit is currently up or that a recorded firewall policy matches the running configuration.

For a small network, a controlled spreadsheet can be a reasonable starting point. The risk appears when records are split across files, ownership is unclear, or people edit the same values independently. A shared inventory becomes more useful when several teams need connected site, device, and address records with a searchable history.

Define a consistent branch record

Give each office a stable identifier that does not depend on a building nickname or a carrier circuit ID. A site name such as SFO-03 or BR-MAD-02 can remain stable while the street address, tenant, and carrier change. Store the human readable name separately from the identifier, and document how new identifiers are assigned so two teams do not invent different names for the same place.

At a minimum, capture the site name, site code, physical address, region or parent group, time zone, local support contact, business owner, and operational status. Add access notes only when the inventory is an approved place to store them. Do not store door codes, VPN passwords, shared secrets, or personal data that the support workflow does not require.

Use the same naming rules for devices and networks across sites. One possible scheme is site-role-sequence, such as SFO-03-FW-01 for a firewall. Treat the name as a label, not as the only identifier. Record the vendor serial number, asset tag, or cloud identifier when it is available, because a replacement device may inherit a familiar name while being a different asset.

Model devices and local connectivity

List the equipment that affects access to the branch network or its support path. Common entries include the edge router, firewall, core or distribution switches, access switches, wireless access points, out of band device, and any local server that carries a critical role. If a site uses a managed service provider, record the provider owned equipment separately from company owned assets.

For each device, capture a stable name, device role, manufacturer and model, serial or asset tag, management address, site, rack or room location, status, owner, and support contract or provider reference where relevant. Add software or firmware version only when a team can keep it current and has a reason to use it. An old version value with no verification context can be more misleading than no version at all.

Interfaces are often where an abstract inventory becomes useful. Record the interface name, purpose, address if static, connected device and port where known, and link to the relevant VLAN or circuit. Use vendor interface names exactly as shown on the device. If your organization adds a friendly label such as WAN-PRIMARY, store it alongside the platform name like ge-0/0/0 rather than replacing it.

When you do not know the cable path, mark it unknown and assign someone to verify it. Never infer a physical connection from two devices being in the same rack or VLAN. For wireless links or carrier demarcations, describe the medium and handoff clearly, including whether the endpoint is a switch port, patch panel, modem, or provider managed device.

Map subnets, VLANs, and routing boundaries

Assign a network owner who approves address space and defines the naming convention. Group branch ranges in a hierarchy that reflects allocation policy, such as regional blocks with one or more child networks per site and function. The exact size depends on devices, guest access, voice, wireless, growth, and whether routes are summarized across a WAN. Do not copy one subnet size to every branch merely because it was convenient at the first office.

For each subnet, record the CIDR, purpose, site, parent allocation, gateway, VLAN, VRF when used, and whether addresses are static, reserved, or allocated by DHCP. If DHCP is managed outside your inventory, document the server or system responsible and the relevant scope identifier, but do not imply that an inventory record is a live DHCP lease database. Record DNS ownership and resolver addresses separately from address allocation if both facts matter to support.

Keep overlapping address space visible rather than hiding it in site specific spreadsheets. Overlap can be intentional when VRFs or acquired networks remain isolated. In that case, include the routing context every time an engineer refers to the address. The tuple of address, subnet, site, and VRF is more meaningful than an IP string alone.

For each VLAN, store its numeric ID, name, purpose, site or deployment scope, and associated subnet where appropriate. A VLAN ID can be reused in a different Layer 2 domain, so avoid treating the number as globally unique. Add the switch or trunk context that determines where the VLAN exists when the team needs to troubleshoot propagation.

Document both ends of every WAN circuit

A circuit record is only useful when both sides are clear. Capture the provider, circuit identifier, service type, committed bandwidth, demarcation details, billing or contract reference, service owner, escalation contact, target dates, and lifecycle status. Link the circuit to the local branch endpoint and the remote office, data center, or provider location it reaches.

If a branch has primary and backup paths, record which one is preferred, how failover is expected to work, and which device terminates each path. A backup circuit that has never been tested should be marked as unverified, not treated as a proven recovery path. Keep performance expectations such as latency or availability targets with the contract or monitoring source that owns them.

Use consistent status values such as planned, ordered, active, degraded, disconnected, and retired, but define who is allowed to move between them. A planned circuit may have an assigned identifier and expected turn up date before the provider activates it. A disconnected service can remain in the inventory for a retention period so previous incidents and invoices still have context.

Connect records to the people and services that use them

Every record should have an accountable owner, even when another team performs the physical work. The network team may own VLAN assignments, the service provider may maintain a managed firewall, and the local office manager may confirm building access details. Record the responsible team or role as well as a contact path. Avoid putting a single person’s name in a field that should survive a role change.

For service context, start by naming the business service or team that depends on a branch link, subnet, or device. If your inventory product does not have a dedicated service dependency model, use a consistent owner field, tag, or external service identifier and keep the authoritative service map in its existing system. A label is a useful cross reference, but it is not a dependency graph. Do not assume that a device has no consumers because no service reference has been added yet.

Separate confidence from lifecycle status. Active means the asset is intended to be in service. It does not mean its current configuration or reachability was checked today. Add a last verified date and a verification source for critical records, and use a review state when the evidence is incomplete. This lets an engineer see the difference between an operational fact and an assumption.

Choose a system of record and access model

Decide where each fact is authoritative before importing records. Your carrier portal may own billing details, a monitoring platform may own uptime observations, and a network inventory may own intended site, device, subnet, VLAN, and circuit relationships. Link out to the authoritative record when it should not be duplicated. If you copy a value for convenience, identify the source and how updates reach the inventory.

Use role based access so local teams can report changes while only designated owners approve address plan or circuit changes. Keep API credentials separate for each integration and give automation the minimum permission it needs. An inventory with a complete change history can show who changed a record and what fields changed, but a change log does not approve the change or prove that the live network matches the record.

For a distributed organization, a shared inventory should allow staff to find a record across sites without relying on one region’s spreadsheet. Obelinf provides site linked records for devices, racks, circuits, subnets, IP addresses, and VLANs, with network topology views built from documented connections. That makes it a candidate for the inventory layer when the goal is to keep these relationships together. It does not replace carrier monitoring, configuration backups, or access control in your device management systems. See multi site network management for how those location records connect.

Roll out one representative branch first

Choose a branch with typical equipment and connectivity, not the easiest site and not the most unusual. Collect the current spreadsheet, diagrams, circuit invoices, device management exports, and local contacts. Mark each value with its source, capture date, and confidence. Resolve conflicts with the person or system that owns the fact rather than picking whichever copy looks newest.

Build the site record, add the edge devices and switches, then map interfaces, circuits, VLANs, and subnets. Add only the addresses needed for operations, and link each address to its subnet and assignment. Keep a list of unknowns. A short queue of explicitly unknown patch paths is safer than a polished diagram that guesses at the connections.

Ask a network engineer and a branch support contact to answer several real questions using only the new inventory. For example, trace the primary WAN path, identify the correct escalation contact, and find the management address for the firewall. Record where they hesitate, what information was missing, and which labels were confusing. Use those observations to refine the fields before cloning the pattern to many locations.

Scale through repeatable rules

When the pilot works, define a template for the common branch types: small office, retail site, warehouse, or regional hub. A template should specify expected roles and relationships, not force every site to contain identical hardware. If a site differs, document the reason and keep its exception visible rather than bending a generic naming rule until nobody understands it.

Prioritize the next sites by operational risk. A branch with one carrier, no local support, or a history of outages may deserve attention before a recently renovated office. Set a realistic pace for importing and validating records, and include the local contact in the review. A bulk import can save typing, but it can also make duplicate or incorrectly linked records at scale, so preview the mapping and reconcile a sample before creating the full set.

Define how you will manage growth. When a branch expands, determine who requests a new subnet, who approves the allocation, who updates DHCP and routing, and who confirms the inventory. When a branch closes, identify who disconnects its circuits, reclaims address space, archives assets, and preserves records for support and billing history. A lifecycle rule prevents a closed location from leaving apparently active resources in the network plan.

Keep the inventory trustworthy

Update the inventory as part of the change that alters the network. A new circuit order, firewall replacement, subnet expansion, or switch move should include an owner and a documentation checkpoint. If the physical change happens before the inventory can be updated, create a follow up task with a due date and a clear reviewer.

Schedule focused reviews rather than asking people to inspect every field all at once. Check carrier endpoints and contacts against provider records, compare device identity with the management system, and sample the address plan against DHCP or cloud sources. Treat differences as work to reconcile, not as proof that one side is automatically correct.

Track freshness for high impact values and define what happens when verification is overdue. Do not silently delete a device or circuit because a query returned no result. An API failure, permission change, or incomplete export can look like mass decommissioning. Require an explicit retirement event or human review before removing connected relationships.

Use a small scorecard to find gaps: percentage of active branches with a named owner, percentage of circuits with both endpoints and escalation details, number of active devices without a site, count of subnets without a purpose, and age of last review for critical records. The measures should reveal missing work, not reward teams for filling fields with guesses.

Make the first inventory useful

Start with one office and the questions your support teams ask during a real incident. Connect each site to the circuits, devices, address space, and owners needed to answer them. Keep ownership and verification visible, distinguish documented facts from live monitoring, and expand only after staff can use the pilot without relying on the old spreadsheet.

If your team needs a shared place to maintain branch sites, network equipment, circuits, and IPAM relationships, Obelinf’s multi site network management workflow brings those records together and links site connectivity in its topology view. Keep monitoring and device configuration in the systems that own those functions, then link them to the inventory where the reference helps operators.