Generally speaking, that's a lot to ask a workflow to do. I'm not sure what limitations there are for the number of tasks that get created, but you might be better off designing this to tasks individually rather than in one go. There are a couple of considerations: Spawning that many tasks is going to put a significant load on the WFE server(s), so there may be performance implications when it runs. There is a good likelihood the workflow won't be reliable given you have a single process creating a large number of items, so if the server is already loaded it might time out.
I think a better way might be to query the AD or SharePoint group or list that contains the 1K users, and store the results in a collection. Then create a For Each action to extract the users from the collection, store that data in a Person or Group variable, and inside of the For Each, add your Flexi-Task using the PoG variable from above. That will "loop" through that list of users, and create tasks individually rather than in one giant action. The benefit here is the safe looping feature will throttle this in batches of 10, so it should work reliably.
My colleague created the workflow shown below going off of your suggestion. When I upload a new document to the library the workflow sent out a task to only one person in the SharePoint group. I assume it is waiting on them to approve the document before continuing? I am going to have her approve the document and see if the workflow continues on to the next person in the group.
Looking at how the workflow is created, do you know why the tasks were not create/sent out to everyone at the same time?
It's kind of hard to tell from the screen shot where the issue might be. I'm assuming you are using the web service call to query a SharePoint group, parsing the results with the Query XML, and storing them in a collection. However, I'm not sure what the query XML inside of the for each is doing.
One simple way to test if the logic is working is disable your Assign Flexi Task. Use a Log in History List action inside of the For Each with the Person or Group variable you are using, and see if it loops through all of the people in the group - the workflow history should show you if it finds a unique value for each cycle of the loop. If there are a lot of people in the group, you may want the workflow to run for a minute or two, look at the history, and if it's working, terminate it so you don't loop through 1,000+ people.
Keep in mind, it won't create all 1,000 tasks in one go specifically because it is inside of a loop.
I don't know if it can help but if you have an AD group inside a SharePoint group and you assign a task to this SharePoint group, it will assign a task to the AD group and not to all the members of the AD group.
I added the log in history list action and tested the workflow. The workflow status shows that it logged everyone in the queried group(Only 10 people). That being said I think you're right.. its the flexi task that is not sending out the task to everyone.
I originally had the flexi task send to about 10 people in a sharepoint group. When I had it send to a group of 10 people or less the flexi task would send to each individual users. For some reason its not working now that I added a web service and for each action... I think the flexi task is the problem. Back to testing for me
With the flexi task action, it waits until the task is terminated (depending on the configuration: until the first has responded or everyone has responded) before executing the next action.
So in your workflow, the foreach is executed one time and wait until the task is terminated before executing the next iteration.
Do you have this behaviour ?
To avoid this, maybe you can use the "Create task" action, or use the "Create item" to create a task in a custom Task list.
Hope this helps