The Replacement workflow if very similar to the Spare workflow, except it does not include the second swap event of devices. Replacement workflow is ideal for districts that do not return devices back to requesters after they have been repaired, and instead allow them to keep the replacement device for the remainder of the school year. This workflow supports an initial swap, for the requester to drop-off their damaged device and pick up a new one, and the subsequent “pick-up” workflow for Agents to retrieve the damaged device before completing the workflow.
From the LocknCharge widget located in the lower right-hand corner of the ticket details page select the Replacement workflow and then Start. The left side of this widget includes a full list of all of the district’s LocknCharge towers. Use the search bar to search by the tower's name, location, serial # or asset tag.
Each tower listing includes:
Tower online/offline status
the name of the tower
total number of bays for the tower (either 5 or 15)
Total number of bays for each status
Please note that while Agents have the ability to view the contents of towers that are offline, it is not recommended for offline towers to be used in ticketing workflows. If towers are offline, workflows are not accurately reflected in the iiQ ticket interface.
After selecting a tower from the list, the agent will then have visibility of each bay in the tower and be prompted to select which bay they would like to use for the ticket they are working.
The bay status, contents in the bay, and tickets a bay is reserved for will all be displayed within this list view to provide context on how other bays within the tower are currently being utilized.
If an Agent wishes to distribute a device that is already pre-loaded into the bay, they’ll want to choose a bay that has an “Asset Available” status.
If an Agent wishes to distribute a device that they currently have in their possession, but still want to reserve the bay for the ticket they’re working, they’ll want to select a bay that has an “Available” status and select the device that they’re issuing to the user.
Bays that are already “In Use” or in an “Offline” status will not be able to be selected.
Bay Statuses in iiQ - These statuses are only applicable for working with bays in iiQ, and do not reflect bay statuses from the LocknCharge Cloud portal.
Online - indicates the tower is connected and includes any of the following bay statuses
Available: Bay is online, empty, and ready for use on a ticket.
Ideal for the “return” use case or any workflow when an asset is not pre-loaded into the bay (IE device or item in Agent’s possession prior to initiating workflow)
Asset Available: Bay is online, contains an asset or item, and ready to be used on a ticket.
Ideal for workflow when bays are preloaded with devices and ready for pick-up
In Use: Bay is online, may or may not contain an asset or item, is reserved for a ticketing workflow (ticket number & link to view ticket will be included with bay status)
Offline - indicates the bay is offline and not available to manage remotely.
After selecting a bay and ensuring that the asset data entered in this field accurately reflects the device being issued for the ticket that the agent is working, they will then need to toggle the prompt that appears below the asset: “Bay is preloaded with selected asset?”
This option should be selected if the device the Agent is issuing has already been loaded into the bay (either via the tower management interface in iiQ or by physically unlocking the tower and loading the bay).
By enabling this option, an email notification is immediately sent to the requestor of the ticket that contains instructions for picking up the device.
By leaving this option disabled, the system will assume that the asset will need to be loaded and bay door will need to be closed before proceeding with the workflow, so the email notification will be sent after the next “bay close event.”
Also, have the option to add any item description to the bay from this interface by clicking the Custom description button. Users can input any text values that describe the contents they’re placing in the bay. After entering the description, they’ll want to click the (check) icon to save the description. Any text entered into this field will also be used in ticketing notifications that instruct requestors of what they’re picking up. But these can only be sent via initiating a LocknCharge ticketing workflow from the ticket details widget.
Example use cases that this option can be used for include:
Adding chargers to bays for distribution if a student or teacher forgets theirs
Adding other device peripherals to the bay for pick-up
Adding documentation or paperwork that must be signed or notarized to the bay
If the bay still needs to be loaded with the selected device or add a custom item description, the following message will be displayed in the ticket details widget after clicking Confirm.
Once the bay has been accessed to load the asset into the bay, and the bay door is closed, the notification will be triggered. The following prompt will appear in the ticketing widget after the notification has been sent.
These notifications can also be referenced in the “emails” tab of the ticket, so Agents and Admins have the ability to see when the email was initiated, who the recipient(s) is(are), and preview a copy of the email notification.
After the requester has accessed the bay to pick up their replacement device and drop off their damaged device, the Agent is notified of the exchange event via the standard “Ticket Updated” notification email for the ticket. This is also captured in the ticket timeline. The replacement device is assigned to the requester at this point of the workflow, and their original device is unassigned from them.
The ticket will be waiting for the Agent to access the bay to confirm the replacement device was picked up and the correct asset was returned. After the Agent completes this step and closes the bay door, the ticket widget will prompt the Agent to verify the exchange details:
The Agent will need to verify the exchange in order to update the asset, ticket, and bay status appropriately. The Agent will need to check the bay to ensure the following:
The correct device was returned to the bay. This ensures the correct asset record is updated in iiQ after the workflow is complete.
They are either leaving the device in the bay or removing it. This ensures the bay status of the tower is updated accurately following the completion of the workflow.
They are unassigning the owner of the device that was returned. This ensures the device ownership is updated correctly following the completion of the workflow.
Once this verification step has been completed,
The bay status will become either:
“Available”, if the end-user toggled the option to “leave asset in bay” OFF during the verification step.
“Asset Available”, if the end-user toggled the option to “leave asset in bay” ON during the verification step.
The LocknCharge widget available from the ticket details page will default to it’s default state, and end users are able to initiate another workflow from its original state if needed.
The asset, either left in the bay or removed from the bay, will either:
Be unassigned; if the user confirms the correct asset was returned and chooses to unassign the device.
Remain assigned to the user that returned the device; if the user confirms the correct asset was returned and toggled the option to unassign the owner from the device OFF during the verification step.
An outline of how the ticket, notifications, and asset data are impacted during each step of the “Replacement” workflow is included below:
Workflow Step | Ticket | Email Notifications | Asset | Bay Status |
Agent initiates workflow by selecting an asset and bay. Proceed to step 3 if device is preloaded. |
|
|
| Updated to “In Use” |
If bay isn’t pre-loaded with asset before initiating workflow, | “Waiting for device to be loaded into tower” widget display |
|
|
|
If bay is preloaded with an asset, these are triggered when the Agent confirms bay being used on the ticket. If bay isn’t preloaded, these are triggered by the next bay close event. | “Pin Email sent to requestor” | (1) Notification sent to end user with instructions for device pickup and drop-off |
|
|
Requester accesses bay and closes door | Ticket timeline is updated to reflect exchange event | Notification sent to Agent notifying them of exchange event | (2) Replacement asset is assigned to requestor of the ticket The asset that the ticket was created for is unassigned from them |
|
Agent accesses bay to verify exchange event + closes bay door | Agent is prompted to verify exchange details |
|
|
|
Agent verifies the correct device was returned to the bay and that the device has been removed | Verification is logged in the ticket timeline as a resolution action |
|
| Bay status is set to either “Asset Available” or “Available” depending on Agent selection during verification step. |
(1) Email notifications are sent to the “submitted by” requester in the event that the ticket is created on behalf of another user. In the near future, iiQ will add support for sending email notifications to associated parent/guardian accounts of the requester if applicable.
(2) Asset assignment logic varies depending on how many requestors are captured on the ticket. If the ticket is submitted on behalf of a user, the device is assigned to the “on behalf of” requester.