Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

Help needed: Building OT Network dashboards in SolarWinds (permissions & best practices)

Hi everyone,

I’m setting up SolarWinds dashboards for an OT (Operational Technology) network and would appreciate guidance from the community.

Context & current status

I have read‑only access today.

I’ve requested read/write permissions so I can create and save dashboards/widgets.

From what I understand, I’ll need the rights to Manage Dashboards/Views (and likely Administrator rights for public dashboards or certain widgets).

Can someone confirm the exact privileges required for modern and classic dashboards?

Ask #1 – Permissions

Which minimum account privileges are needed to:

Create and edit modern dashboards?

Create and edit classic dashboards (views)?

Add Custom HTML widgets (I’ve seen notes that this now requires admin rights)?

Ask #2 – Device onboarding for OT

I’ve already added my network devices.

For OT environments, what are your recommended practices for:

Discovery job design (ranges vs subnets, job size, latency considerations, polling engine placement)?

Polling methods (ICMP‑only vs SNMP; SNMPv3 for security, read/write credentials considerations)?

Credential strategy and ordering during discovery to minimize scan time?

Ask #3 – Dashboard design for OT

For OT‑focused dashboards, what should I watch out for?

Keep dashboards read‑heavy and avoid actions that could impact devices (align with OT change‑control).

Use modern dashboard widgets (KPI, Table, Timeseries, Map) and set sensible refresh rates (global or per widget).

Any recommended starter layouts or widget combinations for plant/site‑level views? Pointers to SolarWinds Lab episodes or docs welcome.

Ask #4 – OT security considerations

OT networks have stricter segmentation (e.g., Purdue model) and sometimes unidirectional data flows. Any tips on:

Architecting SolarWinds to respect zone/conduit boundaries and minimize bidirectional access?

Using unidirectional gateways/replication where needed to bring OT telemetry into enterprise views safely?

General OT monitoring guidance/caveats from CISA/DOE or industry best practice (passive monitoring preference, protocol awareness, logging/time sync)?

Goal

Build simple, reliable dashboards that give OT operations and leadership clear visibility (status, availability, key performance indicators) without increasing risk.

Thanks in advance for any checklists, examples, or gotchas you’ve encountered. If helpful, I can share my initial widget mix and layout once permissions are approved.

Find more posts tagged with

Accepted answers

All comments

NVSteven

You can use 'account_limitations' for limiting permissions on what dashboards can be edited. If the user account editing doesn't have correct permissions, they won't be able add certain widgets but can do any widgets not requiring administrative access.

Complicated queries should be avoided.

Make sure user permissions and data being displayed in dashboards doesn't break any 'need to know'

Tousif_Gemini

I agree with you NVSteven

Deltona

Ask #1 – Permissions
- You will need Manage Views and Manage Dashboards premissions

Ask #2 – Device onboarding for OT
- Before you start scanning, make sure to update the ICMP DATA field under Polling Settings (Orion/Admin/PollingSettings.aspx). Change it to 32 characters.
This is because most older OT gear do not respond to ICMP packets unless they are 32 characters long. Some may even be thrown offline during ping.
Ref: https://solarwindscore.my.site.com/SuccessCenter/s/article/ICMP-Node-can-be-pinged-but-node-showing-down?language=en_US

- No more than 512 IP addresses should be scanned per Discovery Profile
- Do not auto test SSH/Telnet access against OT devices during discovery. The ultra sensitive OT devices will break.
- If using a polling engine, remember to confirm and verify all bi-directional port requirements that a polling engine has with all other engines in the deployment.

Ask #3 – Dashboard design for OT
- Group your devices by area, type and function, then list those that are up and those that are down.
Combine that with event Summary for Today/Last 7 Days along with current alerts. That would be a good start.

Ask #4 – OT security considerations
- Put all engines in one dedicated monitoring zone. Do not stray away from this.
If you absolutely must, then use a remote collector.
- Configure devices to send Syslogs/Traps to the preferred engine.