Problem:
The SNMP Custom Table Sensor has critical limitations:
Sensors are named by row identifiers (e.g., "Table: OID / 128.141.183.198.171.212") instead of human-readable names from string columns
Only one column per sensor - monitoring multiple metrics per table row requires multiple separate sensors
String columns cannot be used for naming or identification
This makes monitoring dynamic SNMP tables (APs, interfaces, VPN users) impractical at scale.

Requested Features:
1. Automatic Naming from String Columns
Add option to specify which table column contains sensor names
Example: Use column .1.3 (AP Name) instead of MAC address
Result: Sensors named "AP-Office-Floor1" instead of "Table: OID / 128.141.183.198.171.212"
2. Multi-Column Monitoring per Row
Allow multiple columns as channels within one sensor per table row
Example: One sensor "AP-Office-Floor1" with channels: Status, Client Count, Uptime
Configuration Example:
Table OID: 1.3.6.1.4.1.14823.2.2.1.5.2.1.4
Naming Column: .1.3
Columns to Monitor: .1.2 (Clients), .1.19 (Status), .1.8 (Uptime)

Result:
Sensor: "AP-Office-Floor1"
├─ Channel: Status
├─ Channel: Clients
└─ Channel: Uptime
Use Cases:
Wireless APs: Monitor status, clients, traffic per AP with readable names
Network Interfaces: Monitor bandwidth, errors per interface with interface names
VPN Sessions: Monitor per-user metrics with usernames
Virtual Machines: Monitor CPU, RAM per VM with VM names

Business Value:
- Immediate identification in dashboards/maps/alerts
- No manual renaming of hundreds of auto-discovered sensors
- Better organization - related metrics grouped per entity

Current Workarounds (all inadequate):
SNMP Library: Creates channels (not sensors), still uses row IDs for naming
Manual renaming: Impractical for 50+ dynamic entries
Custom scripts: Requires PowerShell/Python + PRTG API knowledge
Implementation Suggestion:
Add optional fields to SNMP Custom Table Sensor configuration:
"Naming Column OID" (optional)
"Select multiple columns" checkbox
Backward compatible - existing sensors unchanged
This is a common monitoring scenario that currently has no native PRTG solution.