Skip to main content
Solved

How to implement a semi-annual “user asset attestation” (verify assigned assets) in Freshservice?

  • January 15, 2026
  • 1 reply
  • 41 views

JoramP
Contributor
Forum|alt.badge.img+2

Hi Freshservice Community,

We’re looking for best practices to set up a semi-annual asset attestation process in Freshservice.

Goal:
Every 6 months, each employee should review and confirm the IT assets assigned to them (e.g., laptop, docking station, monitor(s), headset, phone).

What we want to achieve:

  • The employee receives a request to review their assets
  • They can Approve (everything is correct) or Reject (something is incorrect) and add a short comment
  • If rejected, IT can update/correct the asset ownership/assignment and then close the request as “verified”

Questions:

  1. What is the best way to configure this in Freshservice?
    (Service Catalog item + Workflow Automator + approvals, or another approach?)
  2. Is it possible to automatically show the requester’s assigned assets inside the ticket or portal?
    Or is the recommended way to attach an export/report to the request?
  3. Which asset fields do you recommend using to make this reliable?
    (For example: “Used by”, “Assigned to”, location/department mapping)

Any examples, workflow screenshots, or implementation tips would be greatly appreciated.

Thanks in advance!
Joram

Best answer by Roxwell

Oh, I actually like this challenge 😊

The main complexity is making this work consistently across all asset types.

You can’t add fields to the default Asset object, so you’d need a status/date field on every asset type you want to track — which quickly becomes messy.

The next logical place is the User, but the limitation there is that User updates don’t trigger Ticket Scheduled workflows, so you can’t drive this purely from profile changes.

 

High-level approach I’d suggest:

1. Scheduler-driven control

  • Weekly scheduled “Attestation” control ticket via the Scheduler.

2. Event-driven orchestration

  • When the “Next Attestation” ticket is raised:

    • Use an expression to calculate the date window for “due this week”.

    • Web request to retrieve users where the attestation date falls within that window.

    • Loop through the returned users.

3. Sub-workflow per user

  • Retrieve the user’s assets (Reader / placeholders should be sufficient — no extra API call ideally).

  • Send an approval email including the asset list and a custom message.

4. Approval handling

  • Approved

    • Notify the user.

    • Update “Next Attestation Date” = Today + 6 months.

    • Maintain an Attestation Status field (e.g. Not Requested / Awaiting Response / Approved / Rejected / Under Review).

  • Rejected

    • Raise a linked child ticket to IT for review.

    • Set Attestation Status accordingly, so there’s an audit trail against the original Attestation ticket.

    • Add manual tasks for the IT agent to ensure consitency.

5. Asset marking (optional but realistic)

  • You can loop and update the assets, but this means separate custom fields per asset type.

  • In practice, a lightweight audit note (or description update) is often simpler and avoids model sprawl.

6. Operational considerations

  • Watch API limits — batching this (e.g. a couple of runs per week) will be more reliable at scale.

Key data point

  • Add Asset Attestation Date to the User Profile — that becomes your primary control field.

This keeps it automatable, auditable, and scalable without over-engineering the asset model 

 

If I get chance, I will try and build that and make YT, but we’re busy with customer work. 

1 reply

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

Oh, I actually like this challenge 😊

The main complexity is making this work consistently across all asset types.

You can’t add fields to the default Asset object, so you’d need a status/date field on every asset type you want to track — which quickly becomes messy.

The next logical place is the User, but the limitation there is that User updates don’t trigger Ticket Scheduled workflows, so you can’t drive this purely from profile changes.

 

High-level approach I’d suggest:

1. Scheduler-driven control

  • Weekly scheduled “Attestation” control ticket via the Scheduler.

2. Event-driven orchestration

  • When the “Next Attestation” ticket is raised:

    • Use an expression to calculate the date window for “due this week”.

    • Web request to retrieve users where the attestation date falls within that window.

    • Loop through the returned users.

3. Sub-workflow per user

  • Retrieve the user’s assets (Reader / placeholders should be sufficient — no extra API call ideally).

  • Send an approval email including the asset list and a custom message.

4. Approval handling

  • Approved

    • Notify the user.

    • Update “Next Attestation Date” = Today + 6 months.

    • Maintain an Attestation Status field (e.g. Not Requested / Awaiting Response / Approved / Rejected / Under Review).

  • Rejected

    • Raise a linked child ticket to IT for review.

    • Set Attestation Status accordingly, so there’s an audit trail against the original Attestation ticket.

    • Add manual tasks for the IT agent to ensure consitency.

5. Asset marking (optional but realistic)

  • You can loop and update the assets, but this means separate custom fields per asset type.

  • In practice, a lightweight audit note (or description update) is often simpler and avoids model sprawl.

6. Operational considerations

  • Watch API limits — batching this (e.g. a couple of runs per week) will be more reliable at scale.

Key data point

  • Add Asset Attestation Date to the User Profile — that becomes your primary control field.

This keeps it automatable, auditable, and scalable without over-engineering the asset model 

 

If I get chance, I will try and build that and make YT, but we’re busy with customer work.