We have recently implemented a workflow using Nintex Workflow on our system. There are two lists, called User and Submitted.
On the “User” list, any domain users can submit an Nintex form to this list but we don’t want people to see other one’s submissions. So in the Advanced settings of this list, we have set that user can only Read/Create/Edit items that were created by the user.
After an item is added to the User list, a workflow will move this item from the User list to the Submitted list.
In the Submitted list, there is a workflow that sends out a task to a person (Using Assign Flexi Task action) to complete. If the person respond the task as “Send back”. This item will then be sent back to the User list.
Once the initial submitter trying to access the item that was sent back to the User list. They get an “No item found” error message. I noticed once an item is sent back, the “Created By” column has the value of the workflow publisher rather than the initial submitter. So I figured this error is due to the settings that we set on the Advanced settings which limit people to see their own items.
Give full control to the item does not solve the problem, however if the submitter has Full Control on the list, the error goes away.
We really need to let people access the items that have been sent back to the Users list and not giving the people full control.
A couple of approaches that I’ve tried:
Has anyone also tried to update the "Created By" column? How did you do it?
If you have seen this problem before or know a solution to this problem, would love to hear from you.
Solved! Go to Solution.
Actually this wouldn't be an error, but a feature by design. Only that this isn't the design you are looking for. The item was re-created in the User list by the account that published the workflow on the Submitted list. There are ways to change who created the item in the submitted list by moving actions within an action set and run as workflow owner/publisher. Or use the Copy to SharePoint action that provides override credentials. If the list items use the same content type it should be no problem.
With PowerShell, and as an admin, you can change the created by with a listitem.systemupdate(). But that is not an option here. With an update action or create, only changing by impersonation would be the only option.
But, you have many, many, other options here to accomplish the same goal. I just wouldn't know what fits best for you. I can think of a few examples, so here is one that could help.
A second option would be to use only one list. Have a permission group of approvers so they can see all submissions when the time is right. Have views control what users see what items based on status and "see only my items". Have a state machine to control what approving needs to be done based on the status. use tasks to have the status changed accordingly. So in this case there is only one workflow and possibly 2 tasks that keep rotating through the state machine until a happy ending occurs.
1. user creates item, status changed to submitted, moves to submitted state in SM
2. Task for approval, approves and workflow ends, or not
3. Task for approval, rejected, and state changes to "send back" or something else, task created for initiator to update item.
4. Initiator updates item, completes task, status auto changed to "submitted", SM state changes to submitted
5. start over 2-4, until a happy ending occurs
This is a much more efficient solution than the first.
Sorry I breezed through the second option. But there are still more. Hope this is helpful