I’m looking for ideas for including Approver details in the global user's Event Monitor on the Self-Service Portal (under Progress > My Open Issues and Requests).
The issue I have is the Column Profile for the Event Monitor is looking at details on the Request ticket and not the underlying Tasks. If I include Approver as an additional column on the global user’s Column Profile, it appears blank as the Approver is listed on the Task and not the Request. This means end-users are unable to identify who to contact for a pending approval and need to contact our Service Desk to provide the information.
Any advice on if or how other customers are managing similar requirements would be much appreciated.
Best regards,
David.
Page 1 / 1
personally I am not in favor of the requester knowing who the approver is because the process must guarantee that the request will be met regardless of the approver, otherwise the user feels entitled to charge the approver directly. But for the scenario presented, the ideal is that in the main call there should be a field to point out the approver (if he is already known), or this field can be fed by the service desk in one of the steps of the process. Another more complex way would be to use the decision step record as a trigger for the action processor to retrieve the name of the approver and, via rest_update, update the field of the main call
otherwise the user feels entitled to charge the approver directly.Â
I suppose this depends on the type of approver. If said approver is part of their management structure then I would rather them chase directly than generate a call to the IT service desk.
Â
Though we don't do it ourselves, you could try triggering a REST post action from the Action Processor to take an action tailored for this purpose to show in the action history. By using the AP to trigger you would be able to be very specific about when it triggers (for example, when the decision is with the End User SVD). Something Similar to the example below….
2- Criar entrada do action a ser iniciado quando o evento principal iniciar a ação de decisão
  ex.: {        ATUALIZA CAMPO ADICIONAL ],       ON ACT_TYPE_SC == "SC_STAGE_DECISICION" and AV_ATTACHED_PROCESS_SC == "SC_PROCESS" ]],       C_"C:\Axios\Software\SmartMail\send_email.exe" -config "C:\Axios\Automations\SmartMail\Logic\test_uptdate.conf" ACT_REG_ID=$ACT_REG_ID EVENT_ID=$EVENT_ID ]],       "continue"     },       https://wiki.axiossystems.com/assyst11-4Wiki/index.php/Integrations:Action_Processor_Manual
4- chamar arquivo sql no test_update contendo o usuario e atualizar o campo adicional do chamado    https://wiki.axiossystems.com/assyst11-4Wiki/index.php/Integrations:SmartMail_Rule_Dispatcher#The_update_event_ejb_activity    https://wiki.axiossystems.com/assyst11-4Wiki/index.php/Integrations:Using_the_Legacy_assyst_REST_API#Specifying_Custom_Field_values
Thanks everyone for your comments and suggestions. Just to clarify I am referring to approvals from the management hierarchy within the contact user’s own department. Our preference is for users to have visibility of these approvers so they can follow up pending approvals directly.
I think I have enough to go from here to try and set something up. I’ll keep you posted on the progress.
Â
Â
Perhaps the simplest way would be, when starting the approval, to send an email containing the list of approvers.