I discovered yesterday that a standard “Service Agent User” (for instance second/third line Engineers and Service Desk Agents) could “break” the workflow in a Change request by (for instance) amending the “Status” of a Change from “Declined” back to “Awaiting Approval” – the system allowed this and re-sent all the Approval emails to decliners. So – I tried to restrict this.
I assumed that setting a Change back from Declined to a pre-declined state was a “Manage” activity, and therefore amended the “Service Agent User” role to have “Update”, “Create” and “Read” permissions on all the records. I then created a “Service Agent Manager” role which had all of that, plus members of the “Change Management” user group had “Manage – Changes”; members of the “Problem Management” group had “Manage – Problems” etc etc etc.
This has not worked; apparently moving a record outside the normal workflow is an “Update” activity. This means that (as soon as they discover it – which won’t be long) people will be able to remove “Decline” decisions at will and thereby break the careful control we have over our management processes.
The preferred resolution to this would be to make uncontrolled status changes outside the workflow’s normal progression to be a “Manage” activity, rather than an “Update” activity, enabling me to restrict its use.
I feel sure that this must be a bug – it cannot be by design?