Enterprise administration
Connected-device administration platform
An enterprise management portal for the organizations, teams, users, devices and licenses behind a remote-assistance service.
The administration portal manages the organizations, users, groups, devices and licenses behind a remote-assistance service. Its screens need to show who can use each device and which operations are available within an organization.
01 / The platform
Manage the operational side of connected devices
The portal supports administration of organizations, groups, users, permissions, devices and licenses. These are related parts of the same service: access and device use depend on who belongs to which organization and how the service is configured.
Administrators work across related records: assigning a device, managing a user or updating a license. Shared editing patterns keep those tasks familiar while preserving their different permissions and validation rules.
02 / Domain operations
Share editing patterns, keep domain rules visible
Organizations, users, devices and licenses all need lists and editing interfaces, but assigning a device is not equivalent to changing a display name. A universal CRUD abstraction can hide the validation and consequences that make these operations different.
I reused tables, filters, dialogs and list/detail patterns while keeping operation-specific validation and API handling in the features. I avoided a universal CRUD editor because device assignments and license changes needed their own rules to remain visible.
This leaves more code in individual features than a universal editor would. It also makes device assignments and license changes easier to review because their validation and consequences stay close to the operation.
03 / Organization scope
Keep queries and actions scoped to an organization
People, groups, devices and licenses form a connected hierarchy. A selected entity cannot be understood independently of the organization and permissions under which it is being managed.
I treated organization scope as part of the workflow, keeping relationships visible in navigation, lists and available actions. A device or user operation needed to retain that context rather than depend on a label above an otherwise generic form.
Organizational hierarchy complicates navigation and access rules. The frontend presents the available operations, while the API must check the organization and permissions for each request.
04 / Failed updates
Make failed updates understandable
Administration screens sit over APIs and device state that can disagree with a user’s expectations. An ambiguous failure can leave an administrator unsure whether an assignment or license update took effect.
I paid attention to validation, empty states and failed-update feedback alongside the main editing flow. Working across frontend and backend concerns helped me distinguish a rejected domain operation from a failed request in the feedback shown to administrators.
The response needs to tell the administrator whether an update succeeded and what to do next. Device and API failures should remain visible even when the surrounding form is shared with other management screens.
Evidence & further reading