All ideas are welcome. Just because the Idea doesn't make it into the product immediately does not make it a bad idea.
When the data is incorrect the reviewers need to reject to a certain role.
Sometimes it is hard for them to determine what role they need to reject due to the scope size, the number of users, number of roles…so having in the audit not only the user but the role from where the data was introduced would definitively make their work easier.
Based on user experience and the feedback I'm getting from the final users, I think the role should be added as well in the audit at least for Conduct to make it more usable for the reviewers. (Or not necessarily the audit, but a way where they can check it quickly, not having to open the documentation every time.)
Sara
If you are referring to the Audit at the Framework level then not is not an option as this audit is used for all web-apps on the DSP framework.
In the Reviewer Workbench, an aggregate of all changes is available as well as a list of what fields are enabled for all roles.
Remember that despite the design of your implmentation a single field could be shared across many roles for editing.
