Intermittent Errors Updating List Item and Setting Permissions

J
Badge +7

I have a workflow in which I must both update an item and set the item permissions. Intermittently the workflow throws an ambiguous error (e.g. "An error has occurred in [name of the workflow]"). E.g. an error occurred somewhere in this series of actions...

Series of actions in a Nintex workflow diagram

In this instance, the "Update Action" item was successful, but the item permissions were not set, and the workflow did not proceed beyond this point.

I've tried reversing the order of these actions (set permissions first, then update item) and have tried with and without the "Commit pending changes" action.

I'm speculating that either I'm stepping on my own toes (one action makes the list item unavailable for the other action) or that users are trying to update the item at the same time (making the list item unavailable), but I don't know how to diagnose this further.

Next step is to create a new text field, write something unique to it in the "Update item" action, then use it in conjunction with a "Wait for item update" action and put that in front of the "Set item permissions" action.

Is there a best practice for this?

12 replies

E
Userlevel 5
Badge +14

try to add pause for action after the first commit

J
Badge +7

Thanks for the suggestion. I've tried that and it doesn't change.

J
Badge +7

I've been busy. Since the last post I've been trying increasingly desperate things to try and mitigate this problem, including:

  • Removing either the permission or the update action.
    • Thinking that these two were somehow interfering with each other I tried the update action only, and the permission action only.
  • Error trapping using Update Multiple Items.
    • The "Update Multiple Items" action allows for error processing. I set up a loop that would keep trying an update if it failed, up to 5 times and send me an email with error details if/when it failed. Was unable to ever "trap" an error using this method, and it appears that it's not the update action itself causing the workflow itself to error.
  • Avoid Locking Issue by Setting Permissions.
    • I tried changing item permissions first to just an admin account, and then making the update, and then changing the permissions back to normal.
  • Test to make sure the update is completed before continuing.
    • Set a variable to the item's modified datetime, then executed the update item action, then used the wait for the item to update action to wait for the modified datetime to exceed the variable before continuing.
  • Tried reversing the order of Update Item and Set Permissions.

Nothing I've tried so far makes a bit of difference. Errors continue to occur intermittently and seemingly at random and (I haven't started gathering metrics on frequency and rate) seemingly at the same rate. Every day I seem to be clearing 10-20 errors (never 2 or 3, and never 50).

My latest theory is "maybe the workflow is just too complicated" so I'm doing what I can to simplify. It's basically a series of 8 "Run if" actions, one of which is intended to run. I'm replacing the "Run if" statements with a single switch statement (does that make any difference under the hood, or just make me feel more organized when I view it?) Next I plan to break the "run if" actions into separate workflows (so my switch statement will select the right workflow to run). I have no reason to believe this will help (better to run two simpler workflows than one complex workflow) but I'm sort of at the "try anything, hope, pray" stage of troubleshooting.

C
Badge +16

Have you tried just a workflow with just the update action to see how that fairs?

also as above but with static values (rather than passing in any variables)

J
Badge +7

I have tried just the update action alone (e.g. I've removed the permission change but within the context of the larger workflow), but not sure exactly what you mean about the static values. Some of those update actions update fields with both static values (e.g. I type in the value); some use workflow variables, and some use the values of other columns.

E
Userlevel 5
Badge +14

so you say the workflow was failing even in the case you removed set permission action?

then it doesn't seem an interaction between the two cause problems.

can you provide any details on update item action? does it update an item which the workflow runs on? or is it an item from a different list?

what type of columns do you update? typically lookups and people fields cause such intermittent problems.

can you try to add commit changes action before update item action? - to proof check whether changes previous collected changes doesn't in fact cause problems, but are applied together with your update action.

J
Badge +7

I'm updating the item on which the workflow is running.

Type of columns I'm updating. In one instance I'm updating:

  • 1 Single Line of Text
  • 1 User
  • 1 Datetime
  • 1 Number

I have added a Commit Changes action before the Update Item actions and will see how that goes.

Thanks for your suggestion.

E
Userlevel 5
Badge +14

I would guess people field causes problems.

it internally behaves like lookup, and as mentioned above these can often cause problem.

could you try without that single field?

J
Badge +7

Thanks so much for all of your suggestions. Errors occur even when this step is removed entirely; however, I did try removing the user field update only for a week, and there is no noticeable change. Errors continue happening at about the same rate.

E
Userlevel 5
Badge +14

I assume you definitely did it, but I'd ask just for sure - have written those values the item is being updated with to history log and checked they are populated and with correct values?

can you spot a pattern when/for what values workflow fails?

try to check whether there might not happen an indirect problem(s).

eg. if you have calculated fields on list and you update (eg.) numeric value to a zero it might cause division by zero.

or if you have configured list item or list field validation that do not pass for updated values.

or if you have configured a field for uniqueness.

or you have configured lookup cascade restriction.

or you have configured max value for some field

etc...

J
Userlevel 2
Badge +11

Hi Jeff,

The permissions issue I'm facing as well on a regular base. What I figured out so far is that it seems to be caused for user accounts that seem to have an issue,  A check you could do for the involved users is to get their User Number, which should be > 0. In my case I ran into users for whom a -1 was returned. Excluding them seemed to complete the Set Item Permissions successfully and not create an issue further down in the workflow (which is odd showing completed actions in green only to crash the workflow further down in the flow). The same issue occurred while adding users to a group using a web service call action; luckily these have an error handling option, which I use to inform the requestor that some users may not have been added to the group, and then continue with the remainder of the workflow.

Did you ever resolved it or submitted a ticket with Nintex support to get it fixed?

J
Badge +7

Hi Jean-Pierre,

What an interesting observation. I never tried capturing the User Number, but will give it a try in the future.

I ended up doing two things that seem to have drastically reduced the rate at which this is happening. I completely rebuild the workflow from scratch, and also reconfigured the way I was persisting "previous" information. What I mean by this is the list has a  "status" field and a "previous status" field. The workflow triggers when the record is modified and checks for a difference between the fields. If different, we know the status has changed and have the workflow react to that and then save the "status" to the "previous status" value, so that both fields are identical again. In many cases I'm also changing the permissions as well as setting the "previous status" value. While previous testing demonstrated that entirely removing the "set permissions" action, or completely removing the "update record" actions had no noticeable effect on the failure rate, I was still concerned that updating a record in a workflow that was triggered by updating the record was maybe not the best practice in general. So I decided to start saving the "previous status" value in a separate list instead (so workflow triggers, looks up previous value in separate list, reacts if different, then updates the previous value in the separate list). The combination of the two...rebuilding the list from scratch and not constantly having the workflow update the record seems to have done the trick. I still get a handful of mysterious workflow errors per month, but nothing like the volume I was experiencing before.

Anyway, thanks for the tip. Our Active Directory service (and network in general) is quite slow and I wouldn't be at all surprised if some latency was affecting things.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings