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)
-
Scheduled Ticket
-
Ticket Workflow (runs when the control ticket is created)
-
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.
-
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:
-
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