The major difference I see between the two actions is that Set Field can only be used to update a field within the current list, whereas Update Item can be used to update values in other lists.  In addition, the Update Item allows you to update multiple fields all at once, and allows you to specify a "where" condition.   I would say that the Set Field action is just a watered down and less powerful action than Update Item but they can both be used to achieve the same thing.  If updating a field in the current list, both should function the same as they are both added to the job queue for processing so performance should be similar if not the same between both.

-Mike

Thanks Mike M‌

Thanks Mike. I always wondered that because I never used Update Item. Now that you say it, I was always in the list I needed to update. It makes sense.

Cesar Santos I would try using the "Commit Pending Changes" action after your Update Items if you are seeing this strange behavior. Usually these errors are caused by very specific things, such as invalid variable types or even a timeout issues.  The Pause action can also correct some of these types of errors as well.

Cheryl,

There's one other major difference. The Update item action will initiate any workflows setup to start when an item in the list is modified. The Set Field action doesn't. This can be very helpful for preventing continuous looping workflows.

Gerard Rodriguez‌ -   I am able to launch a secondary workflow that exists on a list item set to start when Item is Modified by using the Set Field action.  Do you see some different behavior for this action?

Mike, yes the behavior I described above. We use this regularly to prevent looping when we have an OnModify workflow making changes to the item. Can't explain why it behaves that way if you're seeing different behavior - just thought it was by design. We are using NintexWF 2013 v3.1.0.0 if that makes a difference.

Yeah, I'm testing on 3.0.8 on-prem and Set Field does cause item modification to fire.  I'm curious to see what others are seeing in their envs. as well.

Casar,

While you're in the workflow editor, use the Help, About option. It will display your license information.

Hi Cheryl,

Can you mark my answer correct if this is resolved?

Thanks

Yeah and you don't have to use a Commit Pending Changes with Set Field Value

Here is a good reference document on that: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

I am using site workflow to set a field value in a list item. Upon changing the value, a list workflow should be triggered. When the site workflow updates the value, it modifies the item under my name. Hence, when the list workflow is triggered, the "Initiated By" is automatically set to my name. But the problem here is, I should not be having permission to that site. When i revoke my permission, the workflow is failed due to access denied. We do not have a system account. Kindly help me in resolving this issue.

‌

Hopefully you've already solved this but I just now saw your question. I would suggest asking this as a new question, about how to use impersonation for permissions.

A site workflow can be run by someone with read permission on the site/list. For example; if you have a list/library that users only have read permission to but you need them to run a workflow in that list, SharePoint won't allow it unless they have edit permission. Using a site workflow, that they can run, you can start another workflow in that list/library (using Call Web Service) with elevated permissions on their behalf. This can be a very useful tool when acting on otherwise restricted information.

Hope this helps.