Before
An IT administrator had to open the device-management console, search for the requested device, perform the lock, wipe, or shutdown action, and then return to the team conversation to provide an update. Requests with incomplete device details also required a manual clarification before the action could proceed.
How it works
- A bot receives the device-action request from a team conversation, and an agent identifies the requested action and device details.
- The workflow validates the available information, searches for the managed device, or asks the requester to provide more details when the query is insufficient.
- The workflow performs the lock, wipe, or shutdown action, retrieves the result, and posts the status back to the original conversation.
Workflow details
- Conversation trigger: A bot webhook receives a device-management command from a team conversation and passes the message into the workflow for processing.
- Command interpretation: An agent determines whether the requested action is lock, wipe, or shutdown and extracts device-identifying information such as an email address, display name, serial number, device name, or user ID.
- Information validation: The workflow builds a device search query and checks whether sufficient details are available. If the command cannot be acted on, it replies in the conversation with a request for additional information and examples of acceptable details.
- Device action: After locating the managed device, the workflow executes the requested action. For a lock request, it also retrieves the action result and includes the unlock PIN when one is returned.
- Result delivery: The completed action, target user or device context, and relevant result details are posted back to the original conversation thread so the requester can track the outcome without changing platforms.
What changed
Device actions can now be initiated and tracked from the original team conversation. The workflow automatically interprets the command, checks for sufficient device details, searches for the device, routes the request to the requested action, and delivers the result in the same thread; human involvement remains limited to submitting a clear command or supplying missing details.
Work removed
Manually opening the device-management console, searching for the target device, constructing search criteria, executing the requested action, retrieving the action result, copying relevant details, returning to the team conversation, and manually posting the status update.
Expected outcome
An estimated 3–6 minutes saved per request and approximately 2–3 tool changes avoided, based on the documented workflow outcomes.
