> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/guides/workflows/run-device-actions-from-a-workflow.md). # Run device actions from a workflow Lock, erase, restart or unlock a device from a workflow with Iru, Jamf, JumpCloud and Microsoft Intune actions, with an approval before any erase The actions of your device management tool can run inside workflows. A request like "I lost my laptop" can lock the right computer on its own, and a request for a new account can unlock it, without an admin stepping in. Each action runs on one device, and every run is logged on the request, the person and the device. ### Which actions can I use? | Provider | Actions available in workflows | | --------------------- | --------------------------------------------------------------------------------------------------------------- | | Iru (formerly Kandji) | Lock, Erase, Clear passcode, Restart, Shut down, Unlock account, Send recovery key, Send Recovery Lock password | | Jamf | Lock, Unlock account, Add to groups, Remove from groups, Send recovery key, Send Recovery Lock password | | JumpCloud | Lock, Erase, Clear passcode, Clear Activation Lock, Restart, Shut down, Send recovery key | | Microsoft Intune | Reset passcode | The Intune recovery key isn't available in workflows, because it needs an admin's own Microsoft session. You can still send it from the request or the device page. ### Before you start * Connect your device management tool in **Settings → Workspace → Integration library**, with the permissions the actions need. Each setup guide lists them. * The device must be enrolled in that tool and synced in Siit. ### Add a device action 1. Open your workflow, add a step and pick the action under your device management tool. 2. In **Run on**, choose which device the action targets: * **Equipment on the request**: the device selected in the request's Equipment field. This is the default for new actions. If the form has several Equipment questions, pick the one to use. * **Requester's equipment**: the devices assigned to the requester. You can narrow it down to some equipment types, for example laptops. 3. Fill in the settings of the action: * **Lock:** the PIN is generated at each run. For Jamf, you can also add a lock message, with variables. * **Unlock account:** use the only account known on the device, or type a username. Variables work here too. * **Jamf Add to groups / Remove from groups:** pick static groups, either computer groups or mobile device groups. 4. Save the step. The step card on the canvas sums up its target, for example "Requester's equipment · Laptops". ### Erasing a device needs an approval Every **Erase** action has an **Approval required** setting, turned on by default. You choose the approvers the same way as in an Approval step. * The approver sees the device and the person who holds it. * The device is erased only once the approval is granted. * If the approval is rejected, nothing is erased and the step shows as rejected. * If the request is closed before anyone decides, the step is cancelled. We recommend keeping the approval on. An erase can't be undone. ### Where does the lock PIN go? In the Lock action, choose where Siit sends the PIN: * **Privately to the requester**, like a recovery key. The requester must hold the device, otherwise the step fails before locking it. * **As an internal note** on the request. The note never shows the PIN itself, only a reference. Admins who can open the request can see the PIN for 24 hours. See [Recover a locked-out user](/guides/integrations/integrations-iam/get-locked-out-users-back-into-their-account-and-device.md) for how private codes reach the employee. ### Use the device in later steps Each device action returns the device it ran on. Later steps can use **Device**, **Device category**, **Device serial number**, **Device lifecycle**, **Device model** and **Device office location** as variables. You can also add conditions on the equipment of a request: its type, lifecycle, model and office location. ### Frequently asked questions #### Why did the step fail with "several devices match"? An action runs on exactly one device, and Siit never picks one for you. The error lists the matching devices with their serial numbers. Keep only one device in the request's Equipment field, or narrow down the equipment types in **Run on**. #### Why did the step fail with "no device"? No device from that provider matched the target. The error names the target and the filter, for example "No Jamf device in the requester's equipment (type: MacBook)". Check the device is assigned in Siit and enrolled in your device management tool. #### What if the device doesn't support the action? The step fails with a message that says so. Some actions only work on some devices: * Intune Reset passcode and Iru Clear passcode: mobile devices only. * Iru Unlock account: Macs with a known username. * Jamf Unlock account and the Jamf lock PIN: computers only. A locked mobile device only shows the lock message. * Jamf Add to groups / Remove from groups: the device must match the group type, computer or mobile device. * JumpCloud Clear passcode: iPhone and iPad only. #### Does running the workflow again fail if the device is already in the group? No. For Jamf, a device already in the group (Add) or already out of it (Remove) counts as done. #### Can a workflow replace all the Jamf groups of a device? No. Workflows only add or remove groups, so a fixed list never pulls a device out of its other groups. To replace the whole list, use **Update groups** from the device page. #### Where do I see what happened? Failed steps show in the workflow's **History** tab, with a message naming the provider. Every run also adds an event on the request, the person and the device, with the workflow as its author. #### Do my existing workflows change? No. Recovery key and Recovery Lock password steps you already had keep running on the requester's equipment. ### Need help? Contact . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.siit.io/guides/workflows/run-device-actions-from-a-workflow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.