We don’t give any security class permissions to our approvers because we don’t want them to see the other potentially confidential invoices that are in the system. We give the approvers ad-hoc permissions to view/approve specific invoices assigned to them.
We have the workflow set up to send out a ‘Mobile Approval’ email to the approver for them to approve an invoice. This works great when they approve it from the link that is sent in the email! However, we also send them a reminder email if they haven’t approved it within 24 hours. This email has a link that directs them to the document on the web to approve. This does not work! They can view the invoice, but they cannot approve it.
The only way we could get it to work is to give them ‘View’ permissions in the security class - which is not what we want to do because it gives them access to all the invoices.
Is there any other way to allow the user to approve from the web without giving access to view all invoices?
You can assign permissions in the workflow by using the Grant Permissions task. This can then specify who gets what permissions on a document by document basis.
With that being said, there may be a bug with approvals for cloud instances of ECM at the moment.
I just received an update on my ticket which effectively stated that that is the current workaround. This bug is with the development team so hopefully we’ll see an update soon.
I was able to get it to work…so I want to close this topic
I added another Security Class that functions as the umbrella security class for the Workflow (I already have a ‘Replace’ task in the workflow that changes the Security Class and Content Type to AP Invoice as soon as it enters the workflow). I gave this new workflow security class the permission to ‘View’. I kept everything else as it was - remove ad-hoc permissions, assign to approver, grant permission to the approver, etc. This only allows them to see the invoices that are assigned to them, but it also allows them to approve/deny from the browser.
I don’t know if it was intentional to have the Security Class of the workflow override the ad-hoc permissions given to the user, but it was a pain to try and determine why they don’t have access…
I don’t know why the ad-hoc permissions wouldn’t override the security class of the workflow…