IT playbook · AI Employee: Ivy

Device Recovery / Unlock

Device unlocked without visit

Install this playbookBack to marketplace
The problem

Someone's laptop locked out. It's 4pm, they have a demo at 5, and IT is going to take 90 minutes to get to their ticket. Every minute is a productivity hit. Every minute is friction between IT and the employee. And every device unlock touches sensitive tools — MDM, disk encryption keys, recovery codes — that shouldn't be handled ad-hoc.

At a glance
Trigger
Chat + form
Approvals
IT admin approval for factory reset
What it does
Writes to your systems
Systems
Jamf · Intune · Kandji
How it feels in production

An hour-by-hour walkthrough.

3:52pm. Priya's laptop locks after 5 failed attempts. She DMs Ivy: "my laptop is locked out, serial ABC123, I have a demo at 5." 3:52pm + 15 sec. Ivy verifies Priya's identity via a step-up MFA challenge to her phone. Looks up the device serial in Jamf — matches Priya's assigned device. Retrieves the MDM recovery code (Jamf's escrow) and sends it via Slack DM (encrypted transport, message auto-deletes after 24h). 3:53pm. Priya unlocks her laptop with the recovery code, back in. Every step audited: who requested, whose device, when Ivy retrieved the code, what channel it was sent through. Weekly digest to IT lead: unlock volume, unusual patterns (same user repeatedly locking, unusual devices). If the device serial doesn't match the requester's assigned devices, or if the identity verification fails, or if this is the third unlock request in a week — escalates to IT with the pattern flagged. Never silently issues recovery codes for accounts that shouldn't have them.
How it works

Step by step.

  1. 01

    Verify caller identity

    Read the requester's Slack / Teams SSO identity. Step-up MFA challenge to their registered device. If the registered device IS what's broken, escalate to manager-verify or live-video fallback per policy.

    Slack · Teams · Okta · Twilio
  2. 02

    Locate device by serial / user

    Look up the device in Jamf / Intune / Kandji. Verify ownership — does this serial belong to the requester? If not, escalate. Prevents unlock requests on someone else's device.

    Jamf · Intune · Kandji · Context Graph
  3. 03

    Trigger unlock or recovery-key release

    Retrieve the escrowed recovery key from the MDM. Deliver via encrypted Slack DM (24h auto-delete). Or trigger a remote-unlock command directly for supported OS + MDM combinations.

    Jamf · Intune · Kandji
  4. 04

    Log action + notify

    Full audit event: requester, device serial, retrieval timestamp, delivery channel. Confirmation posted to the requester's Slack thread. Weekly digest to IT lead.

    Audit log · Slack
Systems and wiring

What you connect to make this run.

Jamf Pro · Intune · Kandji

read+write

MDM API credential with device-lookup + recovery-key-retrieval scopes. Recovery keys stored in MDM escrow; Ivy retrieves on verified request.

Okta · Twilio

read

SSO identity + step-up MFA. Requester's registered device / phone challenged before any recovery-key retrieval.

Context Graph

read

Device-to-user mapping. Ivy verifies the requester actually owns the device they're requesting to unlock.

What changes

Before and after, honestly.

Time from request to unlocked
Before
45-90 minutes (ticket → IT triage → recovery code)
After
Under 60 seconds
IT time per unlock
Before
~15 min per unlock (context switching + verification)
After
Zero for verified; escalations only
Productivity hours lost to lockouts
Before
1-2 hours per lockout × lockout frequency
After
Under 5 minutes
Recovery-key misuse incidents
Before
Rare but silent (no audit of who received a code, when)
After
Zero (every retrieval audited with identity)
Related

Playbooks that pair with this one.

IT

Okta Password / MFA Reset

The identity-side counterpart — same verification model.

IT

Hardware Troubleshooting

The escalation path when unlock doesn't solve the underlying issue.

IT

Proactive Device Health

The proactive scan that surfaces devices heading toward compliance drift.

Frequently asked

Answers about this playbook.

What if the requester's phone is also unavailable (both devices dead)?

Fallback to manager verification or live-video verification per policy. Ivy never issues a recovery key without a verifiable identity path — this is by design.

Can we handle FileVault recovery for Macs?

Yes — Jamf escrows FileVault personal recovery keys; Ivy retrieves and delivers via encrypted DM. Same pattern for BitLocker on Windows via Intune, and Android/iOS device passcodes via the respective MDMs.

What if someone requests unlock on a colleague's device?

Ivy verifies device ownership against Context Graph. Requester + device don't match → escalates to IT with the mismatch flagged. Never issues recovery on a device the requester doesn't own.

Does this cover BYOD devices?

For BYOD in an MDM (personal-owned but enrolled), same flow. For BYOD not in MDM, Ivy can't help — the recovery mechanism belongs to Apple/Google, not us. Ivy will say so and point the user to Apple's/Google's own recovery.

How does this integrate with existing IT ticket workflows?

Coexists. Ivy resolves the unlock in Slack; if the requester wants a ticket record (some teams need it for audit), Ivy creates one in Zendesk/Jira SM with the resolution attached. Otherwise, the audit log is the record.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore IT playbooks