Skip to main content

Hi all,

 

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:

  1. Use the Call Web Service action to give full control to the submitter on the list, then remove the permission once the item is moved to the Submitted list again. This is not ideal because a submitter may have multiple items on the list that were sent back from the Submitted list. If they complete one, their permission is removed and they won’t be able to access other items.
  2. Use the Call Web Service action to update the Created By (Author) column with the submitter’s name. I can use this action to update any other fields except the Created By and Modified By columns.

 

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.

 

Thanks,

Jun

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.

  1. Item is created in User list by UserA
  2. Workflow runs on User list on new item and copies data to list Submitted
    1. but first changes a status field on the list item to "submitted"
      1. assumptions: the item is protected by list settings to only show to this UserA and admins. AND, the list view to the user will only show items that are not in the status of "submitted"
      2. Now the item is hidden from view
  3. Item is created in Submitted list with by workflow owner
    1. Assumptions: UserA, or any other User list user does not have access to list Submitted. Only specified approvers do.
  4. Workflow starts on new list item in Submitted list
  5. Task created to ApproverA
  6. ApproverA "sends back"
  7. Workflow running the task will then find the item in list User, and update the status to "Sent Back"
    1. Assumption: store the id of the item in list User during copy for quick reference back. Do this step in workflow on User list that is creating the item. Very simple step.
  8. Now that the item on list User is visible to the user, they can do stuff.
    1. You can also send them a message from the workflow on list Submitted as a last step.
    2. doing this will prevent the created by from ever changing because the item was never deleted or created by someone else

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

‌

Following up on an old post. If Andrew's answer helped you, please mark it as correct answer to help others on the community looking for similar solutions.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings