Appearance
Giving support teams safe device access
Support needs to find a customer device, see whether it is online, and act on the incident in front of them. Shared account passwords make that impossible to audit. This page is the support-lead version of Set up roles.
Recommended approach
- Create a Support group. Give it the Support Engineer role.
- Put device access tags and network access tags on that group so the pod only sees the customers or environments they cover. Do not leave them on all-devices.
- Put people in the group. Keep their primary role narrow. User invites still need an Organisation Administrator or Administrator as primary role.
- Require SSO when the rest of the organisation does. Directory-managed support users stay read-only in Dataplicity; change them in the identity provider.
- Review audit trails after incidents.
What Support Engineer can do
Support Engineer can see fleet context, acknowledge incidents and alerts, and update status. That is the L1 / L2 job.
It cannot search organisation logs and cannot run device actions (reboot, capture, Remote Shell). That is deliberate: support acknowledges and investigates; engineering changes the device.
When support also needs logs or a shell
Roles stack. Add the extra as a group, not by promoting everyone to Developer.
| Extra need | Add this group role | Still cannot |
|---|---|---|
| Search logs | Engineering Viewer | Change device classes or software |
| Reboot, capture, or Remote Shell | A tightly tagged Developer group (OEM) or Site Operator (customer portal) | Organisation settings, SSO, or devices outside those tags |
Do not give the support pod Administrator or unscoped Developer because shell access is convenient.
What support should not do
- Share one login across the team
- Expose Wormhole services without application-level authentication
- Make engineering or organisation-admin changes from a support account