SharePoint leaving Assigned To field blank in a Workflow Task

Question

Hi,

We are having an issue with occasional Tasks being created by a WF that have a blank Assigned to field.  Solution consists of:

1. A form with a People picker field that allows the user to select and validate the Authoriser name.
2. An Auto-start-on-New SP Designer workflow runs that does a "Collect Data from User action" and assigns the Task to the Authoriser.

Unfortunately, although this worked fine during dev and test, now the solution is live and we are having 150-200 requests per day, we are finding that the WF occasionally fails to fill in the Assigned To details when it creates the Task. (approx 8 failures per 200 requests, ie 4%).

As SharePoint already has the User data field, I am confused why this might fail, and there is no obvious pattern (same auth, 4 work OK then 1 failure). 
Does SP contact the AD again when it creates the Task?

Anything else I should investigate? any suggested fix / work-arounds?

Ruth

---

Ruth, UK

Answer 1

I setup a list in my lab environment (running the June 2010 CU build of WSS) and tried to reproduce the behavior. The list had a user field and the workflow was  set to execute on creation of a new item. It checked if the user name field was not null and created a new item in the default task list assigned to the user selected.

Even under load I was unable to reproduce the behavior you are experiencing. If you can give me more specifics around the steps, conditions, and actions in your workflow I can setup a more exact repro for my testing.

I would also start looking over the workflow logs and the entries in the workflow history and see if you can spot the pattern in the missing entries. From there you should be able to see the execution time and start comparing those to the servers ULS logs and look for errors.

I have also had it be helpful to adjust the conditions of the workflow to e-mail a list of variables and fields during workflow creation. This will give you more browse time information about what the users are doing when the field comes out blank.

Let me know if you have any questions.

Thanks!

Answer 2

Is this an InfoPath form or a New Item form?

For the items that are failing, have you confirmed that the names that should appear in the "Assigned to" field also exist in the User Info list on your site? 

Answer 3

Hi Roland / Tracy

Just an ordinary list with a new item form. No InfoPath.

User names are selected from a SP Group of "Authorisers" that have permissions only on the Task list. So Yes each Auth has a User info record in the Site collection.

In each case the Authoriser data has been saved in the main record, but the Task creation step fails to copy the data into the assigned field.

This last week there have been very fewer instances - any chance it could be doing a AD check and failing? I don't think anything in SharePoint has changed.

Regards

Ruth

---

Ruth, UK

Answer 4

we faced this problem too, we build a web site that have a huge workflow and we use SP designer and like you said we got the blank field like every 50 task once i think this happened because the SP Designer not work well and like Microsoft said to us if you want to build a huge workflow use VS and build the workflow by code because the SP Designer not Constance with the huge workflow

Best Regards

Joe

Answer 5

Hi Ruth,

Thanks for your reply! I'm just looking back over this post and seeing that the problem doesn't come with a convenient/easy to track pattern. If this only happens under load, it may be related to the load itself, or peak hours, but that's going to be hard to determine if we can't predict when to run tools to test (but I bet you already know that).

Also, this has been a bit tricky thing to conceptualize. For instance:

Solution consists of:

1. A form with a People picker field that allows the user to select and validate the Authoriser name.
2. An Auto-start-on-New SP Designer workflow runs that does a "Collect Data from User action" and assigns the Task to the Authoriser.

led to the misunderstanding that Form = Infopath Form. It sounds like you're just filling out the NewItem page that appears. Is that right?

When a user is first added to the site (or when the user first browses after being added as part of a group) SharePoint goes to AD and pulls information about that user. Past that, we store everything in SharePoint's local UserInfo table in the database for that site. We should not be connecting to AD during the creation of an item.

What you could do would be to capture a Network Trace during a slow period, when the Workflow/Task is working, and snap one -- if possible -- when the Workflow/Task is failing to pull the details. The Network Trace could show performance issues going to SQL. Likewise, a SQL Profiler trace could help us see a difference. (If we could predict when to run one.)

Were you able to find any meaningful information in the ULS logs or Workflow History list?

Thanks,

Tracy

Answer 6

Thanks for your assisance on this one Tracy,

It really is a fairly simple 2 List problem.

1. The initial "Request" list (+ SPD Workflow) with a NewForm.aspx and the standard out of the box list form rendering of the form which includes a "Person or Group" field to allow them to select a Business Authoriser from a SPGroup.
2. The Task list - containing the Authoriser Tasks which are created as part of the Sharepoint Designer workflow.

As you say, it is hard to get to the bottom of this as we only get between 3 and 10 of these happening each day (out of 120-200 correctly assigned tasks).

They do seem to happen in bursts, but seem not to be related to the person selected.

The Workflow history shows nothing odd, and the Workflow is still listed as "In Progress", waiting for the Task to be completed. If we terminate and restart the workflow it usually creates the task correctly, so this is our current work-around.

Re. Logs: I also will have to request the log files from Central IT as they need to be gathered from all the WFEs in the farm. Central IT would have to do the SQL profile trace for us too. :-(

PS. Good to hear it is not doing an AD lookup at the Task creation point.

Any other suggestions? Otherwise I'll wait for a 'bad' spate of unassigned Tasks and then put in a request for the Sharepoint 12/Logs files.

Regards, Ruth

---

Ruth, UK

Answer 7

Use 'Pause for duration' action before you use 'collect data from user'. Hope it will solve your problem.

Regards,

Pujan Amatya

 

Answer 8

Hi Puzan, Good tip.

Yes we are already doing a "Pause for duration" action 1 min (to ensure a field recently updated by the workflow is correctly used in the task).

Ruth

---

Ruth, UK

Answer 9

Does the user who should show up in the assigned to, already exist in the All people list of the site collection? We have seen a similar case where this was the issue. Once we added the user to all people, the next time the person was populated correctly. We then had to change our code to include the ensureuser method of SPweb.

Answer 10

are you doing this?

assignedto =   workflowProperties.Web.EnsureUser("blah\lfirst")

Answer 11

Hi,

As detailed above, we are using SharePoint Designer Workflows.

I do not think there is an equivalent SPD Action I can use?

(I will bear this in mind if we do get the go-ahead to develope a Visual Studio workflow in future).

Thanks

Ruth

---

Ruth, UK

Answer 12

At a high level, can you describe the process of your workflow?

For your "Collect Data From User" action, who is the user? Specifically, is it a specific user, a group, or a variable based on a previous action?

---

Planet Technologies || SharePoint Task Force

Answer 13

Hi Roland,

Our SPDesigner WF has a single 'Collect Data from User' action which uses the Business Authoriser field (which was a People field) from the Item driving the Workflow instance.

The Business Authoriser field is set to allow selection of a member of the Authorisers sharepoint permissions group, so the selection is Current Item, Authoriser field. This is a single user.

The Task is normally then created and the user receives a notification to the email defined in the User Profile.

- except for the 4-8 per day which fail to set the Assigned To field. :-(

Thanks for your time.

Ruth

---

Ruth, UK

Answer 14

Have you found any solution? we've got the same staff - about 5% of running workflows with get data from user activity fail with emty assigned to field...

 

Answer 15

Hi brbrbr,

We still have this as a live issue. We occasionally have spikes of unassigned tasks during a day.

We also have a related issue resolving people fields within our forms. http://social.msdn.microsoft.com/Forums/en-US/sharepointsearch/thread/b175048e-94a0-48dc-bfc5-e83f63c0a315

In our environment it would appear that both these issues could be related to the complex network infrastructure (multiple replated domain, some NT4), plus the many 10,000s of user records that the validation is being done against.

As we have spikes there a number of these assigned to problems occurr within a (say) 2 minute period, then the assumption is that this is a 'Network busy' or 'AD busy' issue, rather than an internal SharePoint problem.

There is no obvious way around this currently (as I do not have access to check the server event logs of SP logs in the 12 directory).

We may decide to create a separate 'check task' Workflow within the Tasks list eventually.

---

Ruth, UK

Answer 16

Any progress on this issue?

We have a similar issue with a SPD 2007 WF.

1. The item is created in a custom list that starts a WF on creation.
2. The WF checks and calculates a few date fields, sets a Status field
3. The WF then pauses for a "Person or Group" filed to be populated
4. Then the Status is changed and we added a (first a 1min, now 5 min) pause before using the Collect Data assignment of a task to the group.

I look at the History, and the user is there in the field. As in your case this is very intermittent and now that you mention it, seems to happen in groups. We don't have the volume so I can't see it being a factor.

We use the Collect Data several times in the WF and this is the only one so far that is failing.

 

---

Stunpals - Disclaimer: This posting is provided "AS IS" with no warranties.

Answer 17

Hi Stunpals,

This issue is still wth us and still causing a problem.

It appears not to be isolated to a single SPD WF.

We have 2 sites within a Site collection, both have a list with a SPD WF, both have this blank "Assigned To" issue (- in total about 8-20 times a day for 360 tasks).

Basically the WFs are both  "Auto-start on New List item" (custom list) (also possible to manual start):

1. Item is created, and has a "pick an authoriser" field
2. WF populates some variables and fields then does a "pauses for 1 minute"
3. (Some extra validation and email step happens in one WF at this stage)
4. logs WF history msg then does a "Collect Data from User" action to assign the Task
5. Waits for task to complete.

FYI only one of the WFs does step 3 above - and this one has noticably fewer blank Assigned To incidents, but some of the emails fail instead!

I have just been given access to a Test server on our corp network which may make it easier to check the server logs. (Live site is hosted on a Large Farm and checking logs is not feasible.)

I'll try and update this thread if I find what causes our problem.

Ruth

---

Ruth, UK

Answer 18

Another tech here found what looks like a good app to view SharePoint Trace logs. I haven't used it but saw him using it. It seems to display the logs in a more readable fashion, color coding different events with a preview pane for the full error.

http://code.msdn.microsoft.com/ULSViewer

We haven't spent much time on this as we are troubleshooting another unrelated mre pressing issue.

I would be very interested in your results.

---

Stunpals - Disclaimer: This posting is provided "AS IS" with no warranties.

Answer 19

Same happening to me  sharepoint 2007 server not a big load ~10 requests a day.

Using SPD for workflows.

 

I found that occasionaly user is resolved as "Name LastName" instead of "domain/account"

when that happens tasks gets assigned to nobody.

---

Tadas

Answer 20

Did anybody ever find a resolution to this problem?

We are having the same issue with the additional issue of the collect data from user firing twice, once assigned to the correct person, the second time the assigned to is blank, that is the task that moves the workflow on.

Have spent several hours with consultants, now working with Microsoft for four days now, no answer. They seem to think it's a rights issue, but I don't agree as the people submitting the request, have contribute rights to all necessary lists.

Answer 21

If it was rights then it would  happen all the time, so  their answer makes no sense.

I've tried pausing, thinking maybe its grabbing the UserName too early before the record has been updated but that doesn't help.

Taking @T.Blinda comment, I wonder if its possible to add a text column to the collect data request and populated it with the same [Assign To] columns value. Or in the list where the where the WF is started and cache the same [Assign To] column just prior the Collect Data request.

Maybe it will show the value that its trying to put into the [Assign To] column, hopefully its not blank as well but an value that is not valid for a [Person/Group] column.

Just a thought, sorry I don't have time to test this myself, working on a migration to SP2010 and hoping this issue goes away.

---

Stunpals - Disclaimer: This posting is provided "AS IS" with no warranties.

Answer 22

I changed [Show field] from [Name] to [Account]. Then in a form field is displayed as [domain\account] and in SPD WF

it always gets it as account [domain\account]. works for me.

---

Tadas

Answer 23

Hi Ruth,

We are having excatly the same issue. The assigned to field is blank 5 out of 10 times. Did you ever find the cause of this issue. We are using Infopath 2010, and Windows WorkFlow Foundation. We pick users from the AD using people picker on the infopth form. The task gets created but sometimes the Assigned to field is blank. Your posting has been more than  a year, so hopefully you know the cause and can share with us.

Thanks much

TG, US

Answer 24

Hello ,

Try  the following.

 SPUser testuser = onWorkflowActivated1_WorkflowProperties1.Web.EnsureUser("");
 createTask1_TaskProperties1.AssignedTo = testuser.LoginName;

For me this always work.

Best Regards