Skip to main content
Solved

Asset Return - User Status Based

  • February 23, 2026
  • 5 replies
  • 70 views

nickhank19
Apprentice

I’d like to workout a way to address assets associated with deactivated users in our environment to flag for reporting that they need to be returned. 

 

IE, User AD account is disabled, Freshservice Deactivates the account. This signal identifies that a user who has an asset associated with them as ‘used by’ and flips that device state to ‘Awaiting Return’ (or something to that extend. 

 

Is there a way to do this in current state? I’ve been searching the Asset Workflow and cannot find any way to utilize used by user’s status to dictate anything. 

Best answer by Roxwell

 

Hi @nickhank19,

Slightly annoying answer: Freshservice doesn’t currently provide workflow triggers on Requesters/Agents (e.g., “Requester deactivated”), so you can’t natively drive an asset state change from a user’s status change.

 

The practical workaround is a Scheduled Ticket + Ticket Workflow, which periodically checks for deactivated users and then updates any assets assigned to them (Used By) to an “Awaiting Return” status (or equivalent in your instance).

 

Proposed approach (Scheduled Ticket + Ticket Workflow pattern)

 

  1. Scheduled Ticket

  • Create a scheduled Ticket that raises a “control” ticket daily (or hourly if needed) with a subject like:

    • [Check Deactivated Users]

  1. Ticket Workflow (runs when the control ticket is created)

  • Trigger: Ticket is created

  • Condition: Subject equals [Check Deactivated Users]

 

  1. Step 1: Pull requesters deactivated since last run

    Use the requesters endpoint to retrieve recently updated inactive users:

GET https://yourfreshservice.freshservice.com/api/v2/requesters?updated_since=<timestamp>&active=false
Authorization: Basic <base64_api_key:X>
Accept: application/json
Tip: use a timestamp that makes sense (e.g., “midnight UTC” daily), or better: store the “last run time” somewhere (custom object / config) so you only process changes since the last execution.

 

 

  1. Step 2: For each inactive requester, find their assets

    Loop through the requester array and query assets where the “Used By” matches the requester.

GET https://yourfreshservice.freshservice.com/api/v2/assets?filter="user_id:{{loop.data.id}}"
Authorization: Basic <base64_api_key:X>
Accept: application/json

⚠️ Note: Asset filtering support varies a bit by field. If user_id isn’t accepted by the filter in your tenant, the fallback is:

 

  • pull assets by a broader filter (asset type/category if possible)

  • then filter on the returned JSON where used_by_id / equivalent matches the requester id.

 

 

  1. Step 3: Update each matched asset to “Awaiting Return”

    For each asset returned from the previous step:

PUT https://yourfreshservice.freshservice.com/api/v2/assets/{asset_id}
Authorization: Basic <base64_api_key:X>
Content-Type: application/json
Accept: application/json

{
"asset": {
"status": 4
}
}
Where 4 = your “Awaiting Return” state (you’d confirm the numeric ID in Admin → Asset states, since this can be customised).

 

that’s not a perfect working answer, but it’s in the right direction :D 

5 replies

Roxwell
Top Contributor ⭐
Forum|alt.badge.img+9
  • Top Contributor ⭐
  • Answer
  • February 24, 2026

 

Hi @nickhank19,

Slightly annoying answer: Freshservice doesn’t currently provide workflow triggers on Requesters/Agents (e.g., “Requester deactivated”), so you can’t natively drive an asset state change from a user’s status change.

 

The practical workaround is a Scheduled Ticket + Ticket Workflow, which periodically checks for deactivated users and then updates any assets assigned to them (Used By) to an “Awaiting Return” status (or equivalent in your instance).

 

Proposed approach (Scheduled Ticket + Ticket Workflow pattern)

 

  1. Scheduled Ticket

  • Create a scheduled Ticket that raises a “control” ticket daily (or hourly if needed) with a subject like:

    • [Check Deactivated Users]

  1. Ticket Workflow (runs when the control ticket is created)

  • Trigger: Ticket is created

  • Condition: Subject equals [Check Deactivated Users]

 

  1. Step 1: Pull requesters deactivated since last run

    Use the requesters endpoint to retrieve recently updated inactive users:

GET https://yourfreshservice.freshservice.com/api/v2/requesters?updated_since=<timestamp>&active=false
Authorization: Basic <base64_api_key:X>
Accept: application/json
Tip: use a timestamp that makes sense (e.g., “midnight UTC” daily), or better: store the “last run time” somewhere (custom object / config) so you only process changes since the last execution.

 

 

  1. Step 2: For each inactive requester, find their assets

    Loop through the requester array and query assets where the “Used By” matches the requester.

GET https://yourfreshservice.freshservice.com/api/v2/assets?filter="user_id:{{loop.data.id}}"
Authorization: Basic <base64_api_key:X>
Accept: application/json

⚠️ Note: Asset filtering support varies a bit by field. If user_id isn’t accepted by the filter in your tenant, the fallback is:

 

  • pull assets by a broader filter (asset type/category if possible)

  • then filter on the returned JSON where used_by_id / equivalent matches the requester id.

 

 

  1. Step 3: Update each matched asset to “Awaiting Return”

    For each asset returned from the previous step:

PUT https://yourfreshservice.freshservice.com/api/v2/assets/{asset_id}
Authorization: Basic <base64_api_key:X>
Content-Type: application/json
Accept: application/json

{
"asset": {
"status": 4
}
}
Where 4 = your “Awaiting Return” state (you’d confirm the numeric ID in Admin → Asset states, since this can be customised).

 

that’s not a perfect working answer, but it’s in the right direction :D 


Daniel Söderlund
Top Contributor ⭐
Forum|alt.badge.img+14

@Roxwell Hmm you mean using Scheduled Ticket?

 

Scheduled workflow needs a current ticket to run on right ? 


Roxwell
Top Contributor ⭐
Forum|alt.badge.img+9
  • Top Contributor ⭐
  • February 24, 2026

yes, a scheduled ticket, as you can’t run a scheduled workflow without a Ticket or asset. OR, you have a scheduled ticket with a task, and when you change the state of the task, to complete you trigger the w.f


Roxwell
Top Contributor ⭐
Forum|alt.badge.img+9
  • Top Contributor ⭐
  • February 24, 2026

@Daniel Söderlund  that’s what you get for asking to turn your napkin scribble into something sensible  whilst on the train :D  [edited]


Daniel Söderlund
Top Contributor ⭐
Forum|alt.badge.img+14

@Daniel Söderlund  that’s what you get for asking to turn your napkin scribble into something sensible  whilst on the train :D  [edited]

My brain translated for me, haha, I hade to read it several times to make sure I didn’t read it right :)