I am modifying a process that used to allow our users to upload documents directly into a master document library (which turned out to be a bad idea) so that instead they are uploaded to a separate "in tray" library.
After the incoming documents are reviewed and approved by an administrator a workflow will move the item into the master library.
Now, there is no Move List Item action in Nintex, but that's ok because a Move is simply a Copy followed by deleting the original item- right?
However, when I try this it fails. The workflow copies the current item to the target list successfully, but when I execute the Delete Current Item action-
The stack trace is hard to read but basically seems to indicate that an operation has been attempted on an unknown list ID (i.e. the one that's been deleted).
I have re-ordered my workflow so that there are no actions trying to reference the list item after it has been deleted, the delete action is the very last one in the workflow before it exits, and there is a Commit Pending Changes action before the delete, however it still causes the error.
I can see possible reasons for this-
If (2) is the case it makes me wonder why the Delete action exists, and its default target is the current list item(!), but then nobody said it had to make sense.
If somebody could confirm if its possible to delete a list item from a list item workflow linked to that item or not that would be very helpful.
Regards: Colin E
This could be a workaround:
-Create a list named "MovedFiles" with a column named "MovedFileID"
-Instead deleting it on your current workflow, save the id on "MovedFiles"
-Create a new workflow on your "Destination" library named "DeleteMovedFile"
That workflow will delete your moved file
Ah, and then have an Item Created workflow on the "MovedFiles" list that deletes the target. I like it, nice idea!
I was thinking of a slightly cruder workaround (that doesn't need a supplementary list), by having each Item Change workflow look for list items other than itself that are marked as in state ready for deletion and removes them. As changes happen on the list this would worst-case be one step behind (say if somebody moved an item and then stopped work for the day). In my case this would probably be an acceptable compromise.
Another alternative would be a site-level scheduled "reaper" workflow that looks for items that need to be deleted and removes them, but I like your solution because it's event-driven.
Thanks for the idea, much appreciated ;)
Now as to why Nintex / Sharepoint has a delete function that doesn't actually work in it's default configuration?? it's one of the many mysteries of Sharepoint...
I wanted to see if you could share your workflow with us or a screenshot. I set up something on a process that I had which was already moving items between lists.
I added a simply copy/delete workflow that basically copies the item and then deletes it. The workflow does just that; it copies and then deletes. Below are some screenshot of the workflow. The list with the workflow applied and me deleting an item. Running the workflow and the results showing the item has been moved and deleted.
Item is deleted from the list and showing in recycle bin.
Your workflow should not be erroring out.
Hi there, there's no sensitive information in this case so i'm happy to share, although this particular example is (a) Moderately complex at this point; and (b) Slightly oddly structured.
By "Oddly structured", I mean that as I mentioned earlier we have an ongoing problem with the Sharepoint timer job queue on our site, which means I am trying to get this job done while avoiding any of the timer-dependent actions in Nintex. That means no pauses or waits, but also no State Machine, which is something of a pain. The workflow thefore implemements a "pseudo- state machine" using a list _state column and a switch. There is also the usual voluminous use of log statements to try to monitor what's going on.
It makes for a large image (this was stitched together from 5 screenshots), I have greyed-out the parts that aren't relevant to this question, but I suspect the forum is going to scale it down so much it will be impossible to read
The critical paths in the workflow are-
In both cases you will see the delete statement and a pause disabled. At the moment in our environment, the Pause will case the workflow to get stuck (because of the timer queue issue), and enabling the Delete will cause the system to throw up an error BUT the workflow actually runs to completion and the file is moved successfully!
I typed a nice long response and my browser crashed so here is the short version.
Not sure what was inside your actions, but as long as those are not doing anything odd, you should be able to use a copy and delete with no problem.
Let me know if that helps.
I concur with Eric Harris. But before you refactor your workflow, I suggest you create a new "move unit test" workflow using only the Copy to SharePoint and Delete Item actions. I did this in my environment and it worked perfectly. This will confirm that there is nothing unusual about your environment or configuration that is preventing this. Assuming this works, you could then parameterize this workflow so it can be called by your main workflow or convert this to a User defined action.
But the purpose of this is to ensure you can troubleshoot the underlying issue in the least amount of time. If you create this simple 2 step move workflow, and still have the same behavior let us know.
Just to close this one off, I finally came to the conclusion the problem here was my option (1) a timing problem (race condition).
As I stripped things down I got to the point where I realised that even writing a comment to the Nintex log file that referenced a property of the list item, BEFORE the item was deleted, would cause the WF to error.
It seems that Delete List Item is a "fast" native Sharepoint workflow action, while a lot of other actions (like Write to Log File) run asynchronously off the separate Nintex Workflow action queue.
A Pause between the two actions would probably have worked, but as I mentioned above I was constrained to try to avoid timer-dependent actions. In the end I created a separate tiny one-step "Deleter" workflow (with no Logging or other actions!) and ran this from an OnChange trigger when a magic "delete this" value was set on a property of the list item by the primary workflow.
This all feels very kludgy, but that seems to be the nature of the beast when dealing with workflows.