Hi

what error occurs?

does the approver have general permissions to the site too?

"create items and edit items that were created by the user" setting is stricter then item level permissions.

once you disable edit access with the setting you can not grant it back with adding item permissions.

so you will have to use "create and edit all items" setting and then remove edit rights from users that are not managers/approvers within workflow

Hi Marian

My apologies but I realise I've given the wrong information above. In the SharePoint list item-level permissions settings, under Read Access, I have selected "Read all items" (see screenshot). This means that everyone can see ALL items in the list if they have the URL. If I change this setting to "Read items that were created by the user" then the Approver gets the error when he tries to approve "sorry something went wrong, an unexpected error has occurred".

Even by adding a 'set item permissions' action in the workflow to give the Approver 'approve' access, it still won't work.

Any help would be greatly appreciated.

Cassy, the error is "sorry something went wrong, an unexpected error has occurred" (even though I know it's a permissions issue).

And yes everyone has read access to the site that hosts the SharePoint list, and everyone has contribute access on the list itself.

Hi,

I faced a similar issue, have a list where users must only see own items, and tried using same settings as you, because my first solution was to remove all items permission and then set it explicitely to the user in question. But from the time the item was created to the workflow started and permissions was set all users could see the item

Then I tried the "....by user" list setting and I faced same issues as you do, and i ended up back at read/ create/ edit all items (list default) and rely solely on setting item permission as the absolute first thing.

ok.

appart from this setting you still need to grant at least read permissions on source list and at least read permissions on an item being approved to the approver.

plus edit permissions on workflow task list.

do you have it configured this way?

Yes, on the source list everyone has 'contribute' permissions. On the workflow task list everyone has 'approve' access. The issue seems related to the list item-level permissions...'Read items that were created by the user' seems to take precedence over everything else. Here's a few screens (Note the Visitors group contains all staff):

Hi Martin

It seems you had the same problem. When you say ...'and rely solely on setting item permission as the absolute first thing' could you please elaborate on what you did. Do you now have a working solution?

Here's a few screens of my workflow:

you seem to have some custom permission level 'Approve', could you share what right it exactly include?

can you try to 'Check permission' on a source list, an item to approve and workflow task list for a single approver?

I'm pretty sure the 'Approve' permission level is the default SharePoint OOTB...here's a screenshot...

Regarding your second question, sorry but I'm not quite following you. Could you please elaborate a bit on what you'd like me to check?

Thanks

Hi

Here is an example on my structure, in my example I set permissions to some approvers because I have an approval task in "Do something...." and I don't want the initiator to be able to edit the item at this point. Then after approval I give initiator permissions back.

Only drawback here is that from the time the item is created till the workflow executes the first set permissions anyone with site access can see the item. But otherwise it works.

Example permissions:

for lists:

- find 'Share with' on List ribbon in list view

- click 'Advanced' in dialog opened

- click 'Check permission' on ribbon

- in dialog opened enter an approver and click 'Check now' to see what permission he/she is given

similarly for list item, just in first step start with 'Share with' on Item ribbon

Hi Marian

Having checked both the list and list item as per your suggestion, the approver has contribute access on both.

I have done some further testing and what I have discovered is that when I set the item-level permissions to "read items that were created by the user":

then, when the workflow runs, the approver does in fact have access to approve the item. However, the Approver does NOT have access to view the item. In the approval email, if the approver clicks on 'context item display name' he gets an error. However, if he clicks on 'click here to add your comments', he can actually approve the item and add comments. Here's a few screenshots:

workflow email:

Error displayed after clicking on 'context item display name':

Workflow screen after clicking on 'click here to add your comments':

Note, in the above it says 'item no longer exists', even though it does.

So to summarise, the only way the approver can view the item is to change the item level permission to 'Read all items', which is not what I want. I'm very surprised not many others have raised this issue.

Thanks Martin. So, how do you have your list item-level permissions set? Is it 'Read all items' or 'Read items created by the user'? If it's Read all items, then doesn't that mean that all users can see all items in the list at any time, regardless of the workflow, if they have the URL?

yes, that's correct. as I mentioned above, list settings are stricter over permission settings.

but from your above post I understood you've realized this and enabled 'Read all items', but are missing some further permission settings...

Shouldn't this be the expected behavior though, that's where I'm confused. If the approver does not have read rights on the item, then the following will happen

1. The email is missing the item name - can get this earlier in the workflow under the user who started the workflow and save to a variable as a work around
2. Clicking to view the item should through an error to the approver
3. Going to the task item should not display the item details under section item properties, the item name and description are also missing from the top

Since SharePoint forces the Read items created by the user to override the item level permissions. 

In most scenarios, when this comes up, it's common that the Approvers are allowed to see all items in the list they are approving. If no users should see other's submissions then there are a few ways to work with this.

1. Have read all set, then when the workflow starts, change the permissions on the item to remove all users but the current user and the approver group. This kicks everyone else out, but there could be a 30 second or less delay.
2. Have the submission list set to read only items created by the user set. Have the workflow start and it will create another list item in a second list, where only the approvers can read the items. So no submitters can see data. Then after approval, either update the list item permission in list two to allow the initiator see the status, or just email them the approval and not have them go back to the item, or use elevated permissions to update the original item.
3. Use a site workflow with a start form, don't track the data in a list. Just email everyone.
4. I can think of a few ways to change up option two as well. 

Sean,

Martin Lysgaard and Andrew Glasser gave you some good points here. The issue isn't the workflow but understanding how SharePoint is managing or restricting access.

Here is a solution that may help you out, but it doesn't fix the issue with using the advanced list settings that you were trying to use for "read only items created by user".

.

Modify the default view to only show items with the filter criteria for created by is set to tMe]. Most users won't even think to check the view and will assume that the items they see are all that's there. This will hide an item from view but still allow the user to edit and do anything else necessary. This allows you to use the "READ ALL ITEMS" in the list advance settings as you should. 

There is a hierarchy to permissions and SharePoint obeys that regardless of what we do with a workflow. The List Advance Settings set up how the list will be accessed which will override the items user permission because the list is the parent container for the item itself. So if you restrict the visibility of the item at a global list level, the user will not be able to view those items via the Display, Edit and View Pages.

Also, understand that the task approval is not happening directly on that item, but through a Nintex form page which is separate from the display and edit pages, which is why an approver can technically approve the item even though they cannot see it and SharePoint say the items does not exist.  Weird I know.

I did a little testing on this myself and I think you've figured out what works. If you want the user to interact with an item, the list item advanced settings at a minimum would need to be "Read all items". This will allow SharePoint to grant read access to the display.aspx, edit.aspx and view.aspx pages. This has nothing to do with the user, but the items themselves. 

As for what level of permissions for the user, the user can have Read or above such as Contribute or even Edit. This is set on the list by going to the list and modify permissions. This is what you would assign to a group or user. 

Hope that helps and glad you're using Nintex workflows... Keep it up and let us know if we can help. You pulled in support from three of the communities top leaders... 

Cheers!

Thanks to everyone who has offered support here - I appreciate it very much!

There are definitely some workarounds as mentioned above. Even the simple workaround as suggested by Eric of changing the default view, will probably suffice in my case. Good to see some very useful suggestions.

Cheers

Hi ‌, if any of posts above led you to a solution, please select a correct answer.

Yes, please....

It is set to read all items, but as soon as the workflow starts this is changed and item can only be seen by the user that created it.