Switch Port Documentation: The Port Schedule
By WireFlow Team · Published 2026-07-12 · Updated 2026-07-12 · 9 min read
A switch port schedule is one row per switch port that records its untagged VLAN, any tagged VLANs, whether the port supplies PoE, the device (and port) on the far end, and the cable ID. It is the trace map for the network: when someone says "something's wrong," you go from a symptom to the exact port, VLAN, and cable in about two minutes instead of unplugging things until the fault moves. Build it in preproduction from the same diagram that already holds your IP and cable schedules, then keep it as-built. There is a free CSV port schedule template below.
Why document switch ports? The trace map
An undocumented managed switch is a black box with blinking lights. Every port is configured for a VLAN, maybe supplying power, maybe a trunk, and none of it is visible from the front panel. When a device drops off the network, the only tools you have left are guesswork and unplugging cables until the problem moves, which is how a two-minute fault turns into an hour with the show clock running.
A port schedule turns every one of those questions into a lookup. Which VLAN is Camera 2 on? Does port 6 actually supply PoE, or is the panel dead for a different reason? Is the link to the stage switch a trunk, and does it carry the audio VLAN? What is the cable ID so the field tech can find the run? The schedule answers all of it without touching the switch.
The columns, and which are mandatory
A port schedule is deliberately narrow: one row per physical port, and only the fields that let a stranger trace or rebuild the port. These are the columns that earn their place.
| Column | What it records | Mandatory? |
|---|---|---|
| Switch | Which switch or stack member, so the port number is unambiguous across the rack | Yes |
| Port | The physical port label exactly as printed on the switch face | Yes |
| Untagged VLAN | The access (or native) VLAN the port sits on | Yes |
| Tagged VLANs | VLANs carried tagged on a trunk; blank on an access port | Trunks only |
| PoE | The class or planning draw the port supplies, or None; this column feeds the PoE budget | Where PoE exists |
| Connected device / port | The far end, down to its port, so tracing works in both directions | Yes |
| Cable ID | The permanent ID printed on the cable; the join key to the cable schedule | Yes |
| Notes | Anything non-default: forced speed/duplex, LACP group, storm control, a reserved spare | Optional |
Mandatory on every row: switch, port, untagged VLAN, connected device and port, and cable ID. Those five are the trace path. Tagged VLANs matter only on trunks, PoE only where a port powers its device, and Notes only when the port does something a fresh tech would not assume. Everything WireFlow tracks about connecting devices lives in the port-level connection docs; the port schedule is the switch-side view of that same data.
Access ports vs. trunk ports
Every port runs in one of two modes, and the schedule has to say which. An access port belongs to exactly one VLAN and hands the device plain untagged frames; the device never knows VLANs exist. A trunk port carries several VLANs at once, each frame tagged (the mechanism is IEEE 802.1Q) so the far end can sort the traffic back out. Endpoints land on access ports; switch-to-switch links and the occasional VLAN-aware device land on trunks. The full treatment is in VLAN planning for AV systems.
In the schedule the distinction is visible at a glance: an access row has one untagged VLAN and None in the tagged column, while a trunk row lists every VLAN it carries. Get this wrong and the failure is quiet. A device patched into a trunk it does not understand, or a trunk mislabeled as access so it drops most of its VLANs, lands on the wrong network or on none at all, and the link light stays green the whole time.
One system, three sheets: port, IP, and cable
The port schedule does not stand alone. It is one face of a single system documented three ways, and each sheet owns a different question:
- IP schedule owns the addresses: hostname, IP, subnet, VLAN, static or DHCP. See how to create an IP schedule.
- Cable schedule owns the physical run: both endpoints, signal, type, length, loom, and the cable ID.
- Port schedule owns the switch side: which port, which VLAN mode, PoE, and the device on the end.
The join key that stitches them together is the cable ID plus the device-and-port endpoint. A device shows up by IP on the IP schedule, by cable ID on the cable schedule, and by switch port here, and the three cross-reference cleanly. The failure mode is maintaining three disconnected spreadsheets that drift out of sync the first time anything is re-patched. Better to derive all three from one source, see port-to-port documentation. WireFlow documents switch ports on the diagram itself, so the port, VLAN, PoE, and cable are attributes of a connection you can see, not rows you retype in a fourth file.
A worked port schedule
Here is a small managed core switch for a show network, with four VLANs (10 AUDIO, 20 VIDEO, 30 CONTROL, 40 MGMT). Notice that ports 1 and 7 are trunks (they carry tagged VLANs), the PoE ports feed the cameras and panel, and every cable ID matches a row in the cable schedule.
| Switch / Port | Untagged VLAN | Tagged VLANs | PoE | Connected device / port | Cable ID |
|---|---|---|---|---|---|
| CORE-SW1 / 1 | 40 MGMT | 10, 20, 30 | None | Gateway / LAN1 (uplink trunk) | N001 |
| CORE-SW1 / 2 | 10 AUDIO | None | None | Audio console / Net A | N002 |
| CORE-SW1 / 3 | 10 AUDIO | None | None | Stagebox / Net A | N003 |
| CORE-SW1 / 4 | 20 VIDEO | None | PoE+ / ~25 W | PTZ Cam 1 / LAN | N004 |
| CORE-SW1 / 5 | 20 VIDEO | None | PoE+ / ~25 W | PTZ Cam 2 / LAN | N005 |
| CORE-SW1 / 6 | 30 CONTROL | None | PoE+ / ~30 W | Touch panel / PoE | N006 |
| CORE-SW1 / 7 | 40 MGMT | 10, 20, 30 | None | STAGE-SW2 / Port 1 (trunk) | N007 |
| CORE-SW1 / 8 | 40 MGMT | None | None | Record laptop / NIC | N008 |
Read it as a stranger would. Camera 2 is down: find it on port 5, VLAN 20, PoE+, cable N005, and you already know the three things that can be wrong (link, VLAN, or power) and the cable to check. No probing, no unplugging, no calling the person who built it.
PoE per port feeds the budget
The PoE column is not a yes/no checkbox. Record the class or planning draw per port, because the sum of those figures is the number you check against the switch's PoE budget. A switch that runs out of budget does not throw a clean error, it just stops powering the next device, and an exhausted budget gets misdiagnosed as everything except what it is. The per-port math and how to size it live in PoE budget planning.
Keep it as-built
The schedule you write in preproduction is the proposed network. What actually gets patched at load-in drifts from it: a port dies and the device moves to port 9, the house hands you a different uplink, a camera changes position. Update the schedule while the change is fresh, at load-in, not from memory a week later, and mark its state and date. The as-built is what you hand the client and what makes the next show at that venue start from truth.
This is where documenting ports on the diagram pays off. Because the port, VLAN, PoE, and cable are attributes of the connection in WireFlow, moving a wire updates the schedule instead of leaving a spreadsheet stale, and you export the port schedule with the cable schedule and gear list from the same project. If you would rather start from a blank sheet, the free CSV port schedule template has the columns above ready to fill.
Frequently asked questions
- What is the difference between a port schedule and an IP schedule?
- They document different layers of the same network. The IP schedule owns addressing, hostname, IP, subnet, VLAN, and static or DHCP status. The port schedule owns the physical switch side, which port a device lands on, its VLAN mode, PoE, and the cable ID. They share the device and the cable ID as join keys, so you can pivot from an address to a physical port and back.
- Do I need to document every empty port?
- Not every empty port needs its own row, but record which ports are deliberately spare, disabled, or reserved for an uplink. A blank row is ambiguous, it could mean not-yet-documented or intentionally empty, and that ambiguity is exactly what you cannot afford during a fault. A short note like "spare, disabled" removes the question.
- What about unmanaged switches?
- An unmanaged switch has no per-port VLAN or PoE configuration to document, but it is still a node on the map. Record the switch, its uplink port on the managed switch, and what hangs off it. The unmanaged five-port switch someone added under a table is a classic mystery-fault source precisely because it never made it onto anyone's schedule.
- How do I label the ports physically so they match the schedule?
- Make the Port value in the schedule match the number printed on the switch exactly, and label the far end of each run with its cable ID. Where a device is remote, label the wall plate or patch point with the cable ID too, so the person standing at either end can tie back to the same row.
- Can I generate a port schedule instead of typing it?
- Yes. If your switch ports are documented on the diagram, WireFlow derives the port schedule alongside the cable schedule and gear list, so it stays consistent with the drawing. Otherwise, start from the free CSV template on the templates page and fill the columns by hand.
Document your AV network in WireFlow
VLANs, IPs, PoE, and switch ports live on the same diagram as your signal flow, one source of truth for the whole system.