> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Device lifecycle

> Handle hardware from request to return: a form that produces something shippable, device questions answered from your MDM, and returns that actually come back.

export const Checkbox = ({items = []}) => {
  const [checked, setChecked] = useState(Array(items.length).fill(false));
  const toggle = index => {
    setChecked(prev => {
      const copy = [...prev];
      copy[index] = !copy[index];
      return copy;
    });
  };
  return <div className="custom-checkbox-list">
      {items.map((text, index) => <div key={index} className="custom-checkbox-item flex items-center mb-2">
          <input type="checkbox" checked={checked[index]} onChange={() => toggle(index)} className="mr-2" />
          <span>{text}</span>
        </div>)}
    </div>;
};

Hardware is the IT request that most often stalls, because "my laptop is broken" is not actionable and "please return your laptop" is not enforceable. Both are fixable with structure rather than nagging.

<Info icon="list-check">
  **Prerequisites:** the [IT help desk](/guides/playbooks/it/help-desk) playbook. Device lookups need an MDM connected: [Jamf](/integrations/jamf/overview) for Apple fleets, [Fleet](/integrations/fleet/overview) for cross-platform, or [Intune](/integrations/intune/overview) for Windows.
</Info>

## What good looks like

<Checkbox
  items={[
"A hardware request arrives with the model, the shipping address, and the existing device already on it",
"Responders can see the requester's devices without opening another tool",
"Compliance questions (\"is this machine encrypted?\") are answered from live data, not from memory",
"Every departure produces a return task with a date, not a reminder in someone's head"
]}
/>

<Steps>
  <Step title="Ask for the four things that make a request shippable">
    Most hardware forms ask ten questions and still leave the responder chasing. Four fields cover it:

    | Field               | Type                                        | Why                                                                   |
    | ------------------- | ------------------------------------------- | --------------------------------------------------------------------- |
    | Request type        | Select: new, replacement, repair, accessory | Drives priority and routing                                           |
    | Device or accessory | Select from what you actually stock         | Stops free-text requests for hardware you cannot buy                  |
    | Shipping address    | Text                                        | The single most common reason a request sits for three days           |
    | Existing device     | Text or select                              | The serial or asset tag, so a replacement can be paired with a return |

    Set a default priority per request type. A broken machine and a second monitor should not arrive at the same urgency.

    <Callout icon="link" color="#6B7280">Learn more about [forms](/documentation/tickets/forms/overview) and [custom fields](/documentation/tickets/forms/custom-fields)</Callout>
  </Step>

  <Step title="Let the agent collect the details conversationally">
    People describe hardware problems in a sentence, not a form. Add a rule so the agent gathers the fields one at a time and then publishes a ticket the responder can act on.

    <Prompt description="For laptop replacements and repairs, ask for the asset tag, the preferred model, and the shipping address, one item at a time. Then create the ticket on the Device and hardware form with what you collected.">
      For laptop replacements and repairs, ask for the asset tag, the preferred model, and the shipping address, one item at a time. Then create the ticket on the Device and hardware form with what you collected.
    </Prompt>

    This is better than pointing people at a form link, because the requester never leaves the conversation and the responder still gets structured data.

    <Callout icon="link" color="#6B7280">Learn more about [conversational form filling](/documentation/automate/agents/configure)</Callout>
  </Step>

  <Step title="Put device context on the ticket">
    Connect your MDM and responders stop tool-hopping. Depending on the platform you get device lookups by serial, name, model, or OS, compliance state, encryption and MDM enrollment status, installed software, and last check-in time.

    That last field resolves more tickets than it looks like it should. A machine that has not checked in for three weeks explains a lot of "my policies are not applying" reports.

    <Callout icon="link" color="#6B7280">Learn more about [Jamf](/integrations/jamf/overview), [Fleet](/integrations/fleet/overview), and [Intune](/integrations/intune/overview)</Callout>
  </Step>

  <Step title="Gate the destructive actions">
    All three MDMs expose remote wipe or erase, and Jamf and Fleet can return disk encryption recovery keys. These are exactly the tools to put behind **Requires approval** rather than **Auto-execute**.

    A reasonable split:

    * **Auto-execute:** device lookup, compliance state, software inventory, last check-in
    * **Requires confirmation:** sync or refresh a device, request a policy re-push
    * **Requires approval:** wipe, erase, retire, and any recovery key retrieval, pointed at an approval template with your IT leads

    Recovery key retrieval deserves an approval even though it is read-only. It hands someone the ability to unlock a machine.

    <Callout icon="link" color="#6B7280">Learn more about [tool execution policies](/documentation/automate/agents/configure#tool-execution-policies)</Callout>
  </Step>

  <Step title="Pair every replacement with a return">
    Build a task template for replacements with the return step in it, dated. Tasks are visible on the ticket, so the return is tracked in the same place as the shipment instead of in a spreadsheet.

    A workable template:

    1. Confirm the model and address with the requester
    2. Order or allocate the device
    3. Ship and record the tracking number
    4. Confirm receipt
    5. Return the old device, due 14 days after receipt
    6. Wipe and retire the returned device in the MDM

    <Callout icon="link" color="#6B7280">Learn more in [task templates](/guides/how-to/task-templates)</Callout>
  </Step>

  <Step title="Reuse the same template at offboarding">
    Offboarding is the return half of this playbook with a deadline attached. Rather than building a second flow, attach the return and wipe steps to the task template that lands on IT's offboarding child ticket, so the device work sits alongside the access revocation on the ticket IT already owns.

    <Callout icon="link" color="#6B7280">Learn more in [employee offboarding](/guides/playbooks/hr/employee-offboarding)</Callout>
  </Step>
</Steps>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="A free-text device field">
    You will get requests for hardware you do not stock, and a negotiation instead of a fulfillment.
  </Accordion>

  <Accordion title="No shipping address on the form">
    This is the most common single cause of a stalled hardware ticket.
  </Accordion>

  <Accordion title="Auto-executing wipe">
    It is irreversible, and an agent misreading "wipe my browser cache" is not a theoretical risk.
  </Accordion>

  <Accordion title="Returns tracked outside the ticket">
    If the return is not a dated task, it does not happen.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Employee offboarding" icon="user-minus" href="/guides/playbooks/hr/employee-offboarding" horizontal>
    Where the return step earns its keep.
  </Card>

  <Card title="SLAs and business hours" icon="timer" href="/guides/playbooks/slas-and-business-hours" horizontal>
    Different targets for broken and nice-to-have.
  </Card>
</CardGroup>


## Related topics

- [IT](/guides/playbooks/it/overview.md)
- [Incident intake](/guides/playbooks/security/incident-intake.md)
- [Employee offboarding](/guides/playbooks/hr/employee-offboarding.md)
- [Playbooks](/guides/playbooks/overview.md)
- [Guides](/guides/overview.md)