Brent Ellis Oliver Lampl I have found that regardless of the use of an App Step, tasks created via Nintex actions on the Workflow Tasks list (or a custom task list) do not trigger workflows there to fire "on creation." Here's my steps to reproduce:
Have you found a good work-around? I was looking to generate tasks via Nintex and when those tasks were created run a workflow on the tasks list to setup a look-up column back to the original list (to support SP Connected List filtering for task comment history).
Frank - this seems to be related to my own query:
...changes to list items done by workflows are not treated as changes for triggering other workflows - or so it seems.
This really needs to be answered - because it is quite different from on-premise behaviour, and prevents migration to 365 - quite a show stopper for parallel approvals.
What you are experiencing is a common misunderstanding of what Nintex is doing and in O365. Apps require permissions to touch other Apps which is why you have to enable or activate the "Workflow can use app permission" under site features to enable workflows to manipulate other Apps.
When a list item is created via a person using the User interface to trigger that, it hits the SharePoint Object Model and triggers a start event. This start event then starts the workflow. When a workflow creates an item, it does the same thing on behalf of the person and again triggers that start event which is why you see this happen. It uses a different permission level, but still runs under the users permissions.
The reason a task item created by another task item does not trigger the start event is because it uses a different account to create those and thus can be a security problem which Microsoft wants to prevent. You will notice this with any item update is made using system account, the workflow will not be triggered. This also prevents a looping error from occurring and triggering infinite item creations or workflows from being triggered in the cloud which could otherwise cripple a site collection and affect multiple tenants in a multi-tenant environment.
I hope this helps.
Hello Eric, thank you for your detailed answer. But it doesn't met my issue. (Or I misunderstood your explanation)
My customer has the requirement, that a user can only see tasks on which he is assigned. (Therefore it is necessary to set Item level permissions on the Task Item)
I know, the user who wants to respond to an assigned task needs at least contribute rights on the task.
User A (He has contribute rights), creates a new Item on List A, this triggers Workflow W1 on this list, within this Workflow I have the "Start Workflow" Action, this action starts the Workflow W2 within the context of User B (With full access on all related lists, but not on the sitecollection),
Within W2 are starting several Taskprocesses, for all given user. (Not for User B )
Hopefully you now see my problems, related to your first post. As far as I understand the user who created the task is now User B.
But User C, has to respond to the task. My plan was, as soon as the task where created. My Workflow starts and breaks the permissions for the task just created, removes all permissions and set the permissions for the Assigned To user to Contribute and for the User B on fullaccess.
In other works, my workflow just creates a Task Item, which should trigger my workflow on the Task list to set the item level permissions, to get ensure only the user who is assigned can see the tasks are related to him.
Hope you understand my requirements
That's a lot going on. I will try to state how I understood what you said then a direction to proceed in.
User A creates a new item on List A. This starts Workflow W1 on List A.
Here is a thought.
When the task is completed, you can record the outcome and update the item in List A and delete the copied item from List B using Workflow W3 on List B .
Hope that helps.
Thank you all for your help, and the summery that this is just not possible because of security reasons, prevented by Microsoft not of the product Nintex for Office 365. as written by mail from Eric Harris
Oliver Lampl I think what you wanted to do was ensure only the owner can see their workflow tasks. This is difficult because the task list should have everyone with edit access or they won't be able to view or respond to their own task. You could restrict the corresponding item that creates the tasks so that only the owner can see the tasks created by the owner, but this is through the list not the workflow. The image below is under Advanced Settings on a list and can be helpful for what you mentioned.