Timing problem when retrieving Employee Form Results

[Michael Nau]

We have a timing (?) problem when retrieving the results of an employee form from "asmt_metric_result".

The scenario:

1. An HR Task of type "collect employee info" is created
2. The employee form contains 3 questions with metric datatype "String" and 1 question with metric datatype "attachment" - all questions are mandatory
3. An async Business Rule is triggered when the HR Task changes to "closed complete"
4. The Business Rule retrieves the result records from "asmt_metric_result" and does its magic

This works on a PDI, but on our DEV instance we are encountering...

The problem:

1. we are unable to retrieve all results because the records on "asmt_metric_result"  don't exist yet when the task is completed
2. to verify, we are calling two GlideAggregates when our BR fires - one counts records on "asmt_assessment_instance_question", the other on "asmt_metric_result"
3. there should be one result record for each question record, that is: 4 questions and 4 results
4. however, we're seeing 4 questions records and 1 result record - this is always the "attachment" question

What is causing this delay in the creation of the records on "asmt_metric_result"?

How can we know when to collect the results, if not by looking at the state of the parent task?

[Mohith Devatte]

@Michael Nau is it creating after some time or the questions are not created at all ?

[Michael Nau]

Yes, the Results are created - at the very same second! All records (task, questions, results) have the same created / updated timestamp afterwards, so this is really just a matter of milliseconds. I have found some community content pointing to similar problems in earlier versions, I am going to investigate further...

[Michael Nau]

Another try - moved the BR to "asmt_assessment_instance" with a trigger on "state changes to complete". This gives the same result, when the survey instance completes, the results aren't ready. Very unfortunate behaviour.

[Michael Nau]

I'm pretty sure that this is the culprit. Whatever this locked down script include is doing, it's taking longer on a customer instance (on which I am the only active user at this moment) than on my PDI.

[Community Alums]

If that is the case, why not add an event at the end of that BR so that you can trigger your own processing off the back of it being done?