Customer Portal Environment Visibility — controlled, customer-safe infrastructure views

[fabicarvano]

Customer Portal Environment Visibility — controlled, customer-safe infrastructure views

Context and motivation

As Network Visibility, topology, inventory, physical placement, site presence, monitoring, and circuit capabilities continue to evolve, Breeze is building an increasingly rich structured view of each customer's environment.

Most of that information is primarily useful to MSP operators today. However, a carefully selected subset can also provide significant value to customers when exposed as a simplified, controlled, read-only view.

This discussion proposes evolving the Customer Portal so customers with greater technical maturity or visibility needs can better understand their own environment without requiring the MSP to answer routine questions manually.

Examples include:

• How many assets exist at each site?
• Which assets are online or offline?
• Where is a specific infrastructure asset physically installed?
• At which corporate site is a device currently being observed?
• Is a device on a corporate network or outside it?
• How are the main network components related?
• Are there network devices currently showing problems?
• Which WAN circuits are associated with a site?

This can be particularly useful for customers with multiple offices, network infrastructure, physical equipment, and remote users.

What this proposal is not

The goal is not to expose MSP operations to the customer.

The Customer Portal should not become a copy of the technician console.

Operational details should remain internal to the MSP, including for example:

• raw discovery evidence;
• monitor configuration and thresholds;
• credentials;
• raw SNMP data and OIDs;
• fingerprints;
• troubleshooting evidence;
• collector details;
• internal inference metadata;
• execution/debug information;
• technical topology configuration.

The proposal is to expose only explicit customer-safe projections of data Breeze already has, or is in the process of gaining.

Conceptually:

Full Breeze data
      |
      v
MSP operational view
      |
      | explicit projection
      v
Customer-safe layer
      |
      v
Customer Portal

The Portal should answer:

What is happening in my environment?

not:

How is my MSP operating and troubleshooting my environment?

MSP control remains required

A second principle is to preserve the current visibility-control model.

The MSP should continue deciding which information is made visible to each customer organization. This proposal should not force every partner to expose the same amount of technical detail.

For example, one organization might have:

Network Visibility       ON
Physical Placement       ON
SNMP detail              OFF
Topology                 OFF
Observed Location        ON

while another MSP/customer combination may use a different set.

The exact split between capabilities that remain under enableNetworkVisibility and capabilities that deserve their own explicit opt-in should be decided before implementation specs are written.

For richer or potentially sensitive infrastructure views, explicit opt-in may be more appropriate, following the existing Portal visibility model.

Existing foundations and remaining gaps

The intent is not to create seven new subsystems. In most cases the underlying data or service already exists, and the missing piece is a restricted Customer Portal projection.

Proposed wave	Existing foundation	Proposed gap
CPEV-W1 Physical Placement	Physical Placement already exists	Customer-safe Portal projection
CPEV-W2 Network Site Health	Network overview, sites, and assets already exist	Customer-safe per-site aggregation
CPEV-W3 Network Asset Detail	Network asset listing already exists	Stable customer-safe per-asset detail view
CPEV-W4 Advanced SNMP	SNMP/metrics exist; advanced Portal SNMP was previously considered	Revalidate direction and define Portal contract
CPEV-W5 Customer-safe Topology	Technical topology already exists	Reduced customer-safe topology projection
CPEV-W6 Observed Location	Site presence / observed location exists	Customer-safe location projection
CPEV-W7 WAN / Circuits	Backend foundation is evolving	Portal projection once the foundation is stable

To avoid confusion with waves from other Breeze features, this proposal uses the prefix CPEV — Customer Portal Environment Visibility.

Proposed waves

CPEV-W1 — Physical Placement Visibility

Problem: Breeze already has structured physical placement data, but no dedicated Customer Portal projection for it.

Direction: expose a small read-only view when the data exists:

• site;
• room;
• rack;
• rack unit;
• height in U.

Example:

Switch Core 01

Physical location
Site: São Paulo
Room: Main datacenter
Rack: R02
Position: U18
Height: 1U

For assets where placement is unavailable or irrelevant, the section can simply be omitted.

Not a goal: expose placement authority/reconciliation internals, discovered-asset/device reconciliation logic, or unnecessary internal identifiers.

The backend foundation already exists, so this wave would mainly be a customer-safe projection.

---

CPEV-W2 — Network Site Health

Problem: Network Visibility already exposes sites and assets, but the customer has limited consolidated visibility into the state of each location.

Direction: aggregate existing customer-safe signals by site, without creating a new health-scoring engine.

Example:

São Paulo

42 assets
39 online
2 offline
1 unverified

12 devices monitored through SNMP
1 network monitor down

2 active alerts
Highest severity: High

Potential signals include:

• total assets;
• online/offline/unverified;
• SNMP-monitored devices;
• network monitors down;
• active alerts and highest severity when alert visibility is enabled;
• last valid observation where an authoritative source exists.

Important: this wave should not invent a new site-health score. It should aggregate existing canonical signals.

Not a goal: expose monitor configuration, thresholds, raw monitor results, discovery internals, or alert rules.

---

CPEV-W3 — Network Asset Detail

Problem: the Portal can already list network assets, but there is no stable customer-facing detail projection for a single asset.

Direction: create a customer-safe asset detail surface that can become the aggregation point for other approved waves.

Example:

SW-CORE-01

Type: Switch
Manufacturer: Ubiquiti
Model: USW-Pro-48
Site: São Paulo
IP: 10.10.1.2
MAC: AA:BB:CC:DD:EE:FF
Status: Online
First seen: 2026-09-03
Last seen: 2 minutes ago

Over time, the same detail view could compose additional approved blocks:

Network Asset Detail
        |
        +-- Identification
        +-- Reachability
        +-- Physical Placement
        +-- SNMP
        +-- Observed Location
        +-- Alerts
        +-- Related Tickets

Not a goal: expose raw fingerprints, open ports, discovery payloads, monitor configuration, thresholds, raw neighbor data, collector information, or inference metadata.

---

CPEV-W4 — Advanced SNMP Visibility

Context: Advanced Portal Visibility previously reserved an on-hold Network SNMP direction. This discussion provides a concrete customer-facing use case and asks whether that direction should now be reactivated.

Direction: expose only selected structured SNMP information that is useful to a customer.

Example for a switch:

Switch Core 01

SNMP: Healthy
Uptime: 43 days

Interfaces
Port 1  Up    1 Gbps
Port 2  Down
Port 3  Up    1 Gbps

Where authoritative structured data exists, this might also include:

• interface speed;
• inbound/outbound traffic;
• interface errors.

For printers, where supported:

Printer-01
Black toner: 72%
Total pages: 42,183

Never expose: SNMP communities, usernames/passwords, credentials, raw OIDs, raw SNMP payloads, templates, polling configuration, or internal monitor rules.

Question: does it make sense to reactivate the previously considered advanced Network SNMP Portal capability? If so, should it remain outside any “Enable all” behavior and require explicit opt-in?

---

CPEV-W5 — Customer-safe Network Topology

Problem: Breeze now has an increasingly rich technical topology, but the internal topology model contains more operational detail than should be exposed to customers.

Direction: create a reduced customer-facing projection of the main relationships in the environment.

Example:

                 Internet
                    |
               Firewall-01
                    |
                SW-Core
              /     |     \
            AP-01 Server Printer

Possible node fields could include:

• display name;
• asset type;
• manufacturer;
• model;
• reachability state;
• IP where appropriate.

Relationships should also use a deliberately small contract.

Important: do not build a second topology engine. The Portal projection should consume existing canonical read models/services and reduce them to a customer-safe contract.

Not a goal: expose raw topology payloads, collector evidence, raw neighbor information, routes, fingerprints, inference metadata, or debug attributes.

---

CPEV-W6 — Observed Location Visibility

Problem: Breeze can now distinguish the administratively assigned site from the network where a device is currently being observed. This can be useful for customers with multiple sites and mobile users.

Direction: keep the customer experience intentionally simple.

When there is sufficient positive evidence, the Portal would expose only two customer-facing labels.

Corporate network

When the existing site-presence logic confirms a device is on a known site's network:

Network location
Corporate network — São Paulo

Home office / External network

When an existing authoritative signal can positively establish that the device is outside known corporate networks:

Network location
Home office / External network

The Portal would not attempt to distinguish home, hotel, customer site, hotspot, airport, or other external scenarios.

Inconclusive evidence

A key requirement is that absence of a corporate match must not automatically become evidence of an external network.

If the existing presence engine cannot establish a customer-safe location with sufficient confidence, the Portal can simply omit the network-location field for that device.

This keeps the customer-facing vocabulary limited to two states without inventing a misleading third state.

Assigned site remains separate from observed location:

Assigned site
São Paulo

Observed network location
Corporate network — Rio de Janeiro

This must not move or reassign the device automatically.

Not a goal: expose confidence scores, gateway/MAC evidence, fingerprints, raw history, movement suggestions, daily presence rows, assignment-confirmation state, or inference metadata.

Open question: what existing source/evidence, if any, should be considered authoritative enough to positively classify a device as Home office / External network without introducing a new Portal-specific heuristic?

---

CPEV-W7 — WAN / Circuit Visibility

Context: the WAN/Circuits backend foundation is still evolving. This wave should not duplicate that work or define a parallel data model.

The goal here is only to validate whether a future customer-safe projection is useful once the underlying capability is stable.

Direction: expose basic circuit information such as:

Site São Paulo

Provider: Claro
Circuit: MPLS-SP-001
Bandwidth: 1 Gbps
Service type: MPLS
Associated interface: WAN1
Served sites: São Paulo, Campinas

Operational status

This discussion does not propose deriving Up, Down, or Degraded from circuit administrative state or existence alone.

Operational status should only be shown if a future authoritative monitoring relationship supports it.

Likewise, the Portal should not infer “site unavailable” simply because a circuit has a problem.

Not a goal: expose technical circuit configuration, provisioning internals, reassociation state, credentials, raw interface configuration, or troubleshooting data.

How the waves could compose

A future customer experience could look like:

Network
├── Overview
├── Sites
│   └── Environment summary
├── Assets
│   └── Asset detail
├── Topology
└── WAN / Circuits

And a network asset detail view could eventually compose:

SW-CORE-01

Identification
├── Type
├── Manufacturer
├── Model
├── IP
└── MAC

Status
└── Reachability

Location
├── Assigned site
├── Observed network location
└── Physical placement

Monitoring
├── SNMP
└── Alerts

Relationships
├── Topology
└── Related tickets

Not every organization needs every block. Visibility remains controlled by the MSP.

Shared principles for all waves

If the overall direction is accepted, each wave should follow the same constraints:

Read-only

Increase visibility, not customer control. These waves should not introduce infrastructure mutations from the Portal.

Existing data first

Do not add new collection when Breeze already has the required source data.

Customer-safe projection

Portal contracts should use explicit allowlists. Internal DTOs should not be reused blindly when they may include operational fields.

Auth-derived organization scope

Organization context must continue to come from Portal authentication, not from client-supplied authoritative organization IDs.

Fail closed

If a capability is not enabled, its data must not be exposed.

No operational leakage

A field should not become visible merely because it exists in a table or internal read model.

No duplicated inference

Topology, observed location, reachability, and similar classifications should consume existing canonical services/read models rather than creating Portal-specific algorithms.

Controlled visibility

The MSP must continue to decide which capabilities are available to each organization.

Visibility controls — decision needed

Before individual specs are written, it would be useful to validate whether every family needs an independent flag.

One possible direction is:

Remain under Network Visibility

• Network Site Health;
• Network Asset Detail.

Explicit opt-in candidates

• Physical Placement;
• Advanced SNMP;
• Customer-safe Topology;
• Observed Location;
• WAN / Circuits.

Another grouping may be better. The important requirement is that an MSP can avoid exposing parts of the environment that it does not want to make customer-visible.

Dependencies and sequencing

The waves do not need to ship in one rigid sequence.

A possible grouping is:

CPEV-W1 — Physical Placement
CPEV-W2 — Network Site Health
CPEV-W3 — Network Asset Detail

CPEV-W4 — Advanced SNMP
CPEV-W5 — Customer-safe Topology
CPEV-W6 — Observed Location

CPEV-W7 — WAN / Circuits

W1–W3 appear to have sufficient foundations to be specified first.

W4–W5 primarily need direction and customer-safe contract validation.

W6 has a strong observed-location foundation, but the safe semantics of the external state still need to be resolved.

W7 should wait for the WAN/Circuits foundation to stabilize before any Portal implementation.

Explicit non-goals

This discussion does not propose:

• administrative actions for customers;
• topology editing;
• changing a device's assigned site;
• automatic device moves;
• circuit editing;
• monitor reconfiguration;
• credential exposure;
• raw SNMP exposure;
• discovery configuration exposure;
• inference evidence exposure;
• troubleshooting detail exposure;
• replicating the technician console inside the Customer Portal.

What we are asking to validate

Before creating individual specs, we would like feedback on these points:

1. Overall direction — Does it make sense to continue evolving the Customer Portal toward a controlled, customer-safe view of the customer's environment?
2. Visibility vs operations — Is the proposed separation between customer visibility and MSP operational detail appropriate?
3. Wave boundaries — Do the seven CPEV waves represent sensible implementation boundaries?
4. Visibility controls — Which families should remain under enableNetworkVisibility, which deserve their own control, and which should stay outside any “Enable all” behavior?
5. Observed Location — Is it acceptable to expose only Corporate network — <site> and Home office / External network, while omitting the field when evidence is inconclusive? What existing signal should authorize the external classification?
6. Advanced SNMP — Does the concrete use case justify reactivating the advanced Network SNMP Portal direction that was previously left on hold?
7. Next step — If the overall direction is sound, the proposal is to create one small spec/issue per wave rather than specifying or implementing all seven together.

[ToddHebebrand]

Accepted as a spec, continuing #5438 and #7450 rather than starting fresh. The groundwork exists: portal_branding.enable_network_visibility already gates a read-only network surface built from discovery data.

The bar from those threads still applies:

• One opt-in flag per family of data (network, placement, circuits, monitoring), each off by default and set by the MSP per organization.
• Topology and observed-location views stay outside "Enable all". They reveal the most about internal layout, so each needs its own deliberate opt-in.
• Explicit field allow-lists per wave. The spec names exactly which columns a customer can see. No passthrough of internal records and no jsonb blobs.
• Customer-safe by construction. No credentials, management IPs or internal hostnames unless a field is explicitly listed and justified.

Suggested next step: a spec that maps each family to its flag and field list, with wave 1 limited to data that is already discovered and already org-scoped. Happy to review when you have it.