> For the complete documentation index, see [llms.txt](https://docs.bluefletch.com/bluefletch-enterprise/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bluefletch.com/bluefletch-enterprise/product-guides/virtual-device-locker/workflow-scenarios.md). # Workflow Scenarios These sample scenarios show how Device Locker manages device check-out and check-in across different environments. Each scenario follows a Trigger-System Response structure to illustrate the workflow at each stage. ### General Scenarios #### Scenario 1: Pick up and log in * **Trigger:** A user picks up an available device to start their shift. * **System Response:** Device Locker detects the device via BLE, prompts the user to log in, and records the check-out after a successful login. Device Locker then updates the device status to **In Use**. #### Scenario 2: Badge tap assignment * **Trigger:** A user taps their NFC badge to start a check-out. * **System Response:** Device Locker identifies the user, selects an available device, and sends the assignment details to it. The user picks up the assigned device and enters a PIN or uses Face Recognition. Once login is complete, Device Locker records the check-out and updates the status to **In Use**. #### Scenario 3: Forgot to check in * **Trigger:** A user leaves at the end of their shift without checking the device back in. * **System Response:** Device Locker keeps the device marked In Use under that user. If Device Locker does not detect the device within the configured time period, it updates the status to **Missing / Not Reporting** so an admin can follow up. #### Scenario 4: Returning a device * **Trigger:** A user comes back within BLE range while still logged in. * **System Response:** Device Locker detects the device via BLE and pushes a prompt to the user to check in or continue the session. When the user selects Check In, Device Locker ends the session, logs the user out, and updates the device status to **Available**. #### Scenario 5: Assigned device is unusable * **Trigger:** The device Device Locker assigned after a badge tap is dead or damaged. * **System Response:** The user requests a new device. Device Locker selects another available device and sends the updated assignment details to it. The user reports the unusable device so an admin can update its status in Device Locker. ### Retail Scenarios #### Scenario 1: Covering two departments * **Context:** A team member is scheduled across two departments for the day. * **System Response:** If admins have configured cross-department access, Device Locker allows the user to check out devices from each department they cover. Device Locker enforces the assignment rules admins have set for each pool. #### Scenario 2: No devices available * **Trigger:** All devices in a user's department are currently checked out. * **System Response:** Device Locker shows no available devices for that pool. The user asks a manager whether cross-pool access can be granted, or waits until Device Locker detects a returned device and updates its status to Available. #### Scenario 3: Cross-department device use * **Context:** One department runs low on available devices and needs to draw from another. * **System Response:** Device Locker enforces the assignment rules admins have configured. Admins can open shared access between pools or keep pools restricted so each team retains its own set of devices. #### Scenario 4: Tracking usage by shift * **Context:** A manager wants to review how devices were used across shifts. * **System Response:** Device Locker generates reports showing check-out and check-in history by user, device, and time. Managers can use these reports to review utilization across departments and shifts. ### Healthcare Scenarios #### Scenario 1: Rapid shift change * **Context:** Hospital employees need to hand off devices quickly at the start of a new shift. * **System Response:** The incoming employee taps their NFC badge. Device Locker identifies the user, assigns an available device, and sends the assignment details to it. The employee picks up the device and enters a PIN or uses Face Recognition to complete login. Device Locker records the check-out, keeping the handoff fast and accurate. #### Scenario 2: Urgent replacement during patient care * **Trigger:** A clinic staff's device becomes unusable while caring for a patient. * **System Response:** The staff taps their badge or picks up an available device and logs in. Device Locker assigns the replacement and records the new check-out. The staff reports the unusable device so an admin can update its status in Device Locker. #### Scenario 3: Cross-unit device access * **Context:** A medical professional's unit has no available devices. * **System Response:** If admins have enabled cross-unit access, Device Locker can assign a device from another unit's pool. Device Locker applies the assignment rules admins have configured by unit, role, or shift. #### Scenario 4: Biometric login fails mid-shift * **Trigger:** Face Recognition does not work for a clinician during their shift. * **System Response:** The clinician enters their PIN to complete login instead. Device Locker records the check-out once login succeeds. If biometric issues continue, the clinician reports it so IT can investigate. #### Scenario 5: Audit and compliance traceability * **Context:** A compliance review needs to confirm who held a specific device at a given time. * **System Response:** Device Locker provides reports that capture device IDs, the users associated with each session, and check-out and check-in timestamps - giving auditors a clear, reliable usage history. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bluefletch.com/bluefletch-enterprise/product-guides/virtual-device-locker/workflow-scenarios.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.