Fix Analytics request creator field to stop it changing to Alma staff primary ID when request cancelled on Alma
When a user places a request on Primo, the ‘creator’ field in the Analytics requests table shows as ‘System’. When a request is placed by a staff member on Alma, the staff member’s primary ID shows in the creator field.
If a request placed by a user on Primo is subsequently cancelled by a staff member on Alma, the creator field changes from System to the staff member’s primary ID. This means reporting on requests placed on Primo vs. requests placed by staff members on Alma is not accurate and the field is misleading (creator should refer only to creator).
I logged a Salesforce case about this (00801207) and received the following reply:
“The feedback from Development is that this behaviour is by design, for history requests the creator is indeed the cancelling operator so they can know who completed/ cancelled the request. However, we understand and brought it up to them how confusing it is and not informative since the information about how completed requests were created is being lost. PM has also been updated about this issue.
The conclusion is that Alma is currently not designed to provide the functionality you requested, so the next step is to pursue this as an enhancement.”
Hence adding this suggestion.
Bronwen Blatchford
shared this idea
-
Anonymous
commented
We need to have the possibility to find out if a request has been created by user (via Primo) or by staff. So if this is not possible with the creator-field (as described below), please add another field containing this information. In case users claim not to have requested an item we cannot prove them right or wrong.
-
Chris Jones
commented
By way of further explanation, case 05327094 explains "When a request is canceled, it moves from one Oracle table (active requests) to another (Requests history). In any Oracle table, the creator is the one that 'created' the entry in this table, so when a request is moved to the request history table, the creator is not the user that created the request but the one that moved the request to the history table".
This is extremely unsatisfactory as it rewrites the history of the request in terms.
Completely support this idea. Lack of documentation around this (and after extensive work on Requests analytics when released in 2014) is not great.