Hi Everyone,
We have Reassign, Reject , Accept buttons provided by default in Appian. It is inside a User input task. Since it is a default button we couldn't able to run any rules or write any code to store the value for the buttons.
Eg: If we click on "Accept" button tp!owner is changed but we can't store the value in a table. Similarly if we click on "Reassign" and "Reject" the values are captured in task level but we can't store the value in a separate table.
Is there a way to capture the actions in the backend or generate any report for admins or others to know the actions performed by the user?
Thanks
Discussion posts and replies are publicly visible
I am a friend of process reports to make task related data available. Task metrics can be stored when the task is completed.
A workaround is discussed here: community.appian.com/.../solution-for-initiating-processes-or-writing-data-on-task-acceptance
I usually avoid allowing users to use the OOB "reassign" and "reject" buttons. There's no avoidance of the "accept" button but we just design in such a way as to not need terribly much detail from it, since we've long known that there are severe limitations on what we can expect to get from that.
I haven't yet tried the work-around that Stefan linked, though I also recently became aware of it (basically the gist is that a rule input can be passed the value of "tp!owner" from the user input task configuration context and it'll enable the SAIL form to detect exactly when "accept" is clicked - which i haven't tested yet but it sounds like others have already).
Is there a way to track or capture the action when the user clicks on "Reject" button inside user input task like who rejected the task and when the task was rejected ?
Unknown said:Is there a way to track or capture the action when the user clicks on "Reject" button
Again, nothing that anyone here is aware of, anyway - though if you pass in "tp!owner" as a rule input to the interface, and use local variables correctly to monitor the status of that value, it **might** be able to inform you of "rejection" status (i assume the tp!owner would change from having an initial value to being blank, perhaps) - but like i said, this is an untested work-around, so you'll just have to try it out.