Capturing Approval Duration for Approver in user type approvals

[SiddhiS94372801]

I'm working on capturing approval duration using a metric definition on approver table.

Requirement:
The approval type is user based approval

Multiple users (eg 4-5 users) are assigned at this level

If  any one user approves, the request moves forward as expected

However, the metric is capturing duration for all assigned approvers, even those did not take action

What I want is the metric should capture duration only for the user who actually approves it
Other approvers should not included in duration field

Or any alternative approach to achieve this?

Thanks

[Dominik Simunek]

You might be able to script it by a completely scripted Metric Definition to create only the Metric Instance of your wish, but I feel it can be more complex than needed. You have some other options, I believe:

1) Use the normal field state duration metric on sysapproval_approver, and report on a DB view that joins metric_instance with sysapproval_approver and filters only on those where Approval.State = Approved or Rejected. This way, you filter out all the "no longer required" approvals where the approver did not act.

2) You could also set up additional fields on the sysapproval_approver table that would help to track similar timestamps as common on the Task table - like "Requested at", "Closed at", and "Closed by". They can be populated by simple business rules like the Task table does. Once you have these timestamps on the sysapproval_approver, you can utilize them in the Performance Analytics to also measure the performance on the approval table, like "How long does it on average take to approve/reject a RITM approval?", "How old are the currently open approvals on average per approving table?". Such performance analytics on the approval table can be great as it helps you identify how efficient your approval process is per table/process/application (e.g., fast in knowledge management, but slow in request management -> take some actions). This solution has the downside of the need to add new fields and business rules, but it avoids the creation of thousands of unnecessary metric instances, so it might be better from a database size perspective.