Checkout Loaner Asset

Hello,

Trying to figure out the best way to go about managing our fleet of loaner assets within TDX. Ideally, we'd like to be able to check out loaners on an as needed basis, meaning not every user will place a ticket requesting a loaner on the front end. If this is back-end maintenance we need to manage, that's not ideal but I can live with it. With this checkout process, I'm hoping to have a way to auto-generate emails sent to the end user when the asset is checked out. Examples of emails I'd like to send:

  1. You have checked out loaner asset XXXXXX
  2. Reminder, loaner asset XXXXXX is due on XX/XX/XXXX
  3. Thank you for returning loaner asset XXXXXX 

I know this is possible in other ticketing systems. I'm just trying to figure it out in TDX. Additionally, is there a better way of flagging an asset in the system as a loaner other than using a separate custom asset form? When there's an entire school's worth of assets in the database, that can get cumbersome to navigate.

 

How is everyone else managing their loaners? All suggestions welcome! Thanks!

Tags Custom-assets loaner
Asked by Ashleigh Chandler on Thu 3/7/24 9:00 AM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Mark Sayers Thu 3/7/24 3:22 PM

Hello Ashleigh,

I should think you would be able to build a ticketing workflow that can PATCH the asset record to a certain "Checked out" status and maybe temporarily change its Owner value to be that of the person entering the ticket request. Then when they return it, the workflow can progress to another web service method step that PATCHes the asset status back to checked in and changes its Owner back to the long-term owner of the asset in question.

That would be conceptually how I'd do this. You could track when the asset is due back in a date field, then have a condition step that checks if that date value is greater than or equal to the run date (of the condition step), follow that with a Timer step that waits 1 day before checking again, and follow that with a web service method to just GET the ticket itself (this prevents the workflow from detecting this process as an "automated loop"). That web method just loops back to the Condition so it can perform its check again.

Whenever the Condition step is finally met (meaning we've reached the return date of the asset) you can route the workflow to a Notification step asking the requestor to return the device. Then have a task or Choice step for the tech to either check the item back in or maybe route back to the notification step to ask the requestor to return it again. Once they turn it in, have that web method step I referred to which PATCHes the asset status to checked in and maybe changes its owner value.

Does that make sense?

Sincerely,
Mark Sayers
Sr Support Consultant, CS

No feedback