Hello Frank , Nathan was right, the question in not answered yet. I just added some Tags, and tried to add some additional information, to explain my question with a bit more details

I would also use the workflow start action, but it is just a workaround.

So I still need an answer to my question.

Are you using "App Steps" in your workflow?

No, I don't use "App Steps" in my workflow. Should I?

I don't think so, because currently the workflow is starting in context of an user, who is SiteCollection Administrator, so no elevation is needed.

Not necessarily.  If you create list items from an "App Step" workflows will not trigger, so I wasnt sure if that might apply here, but it doesnt sound like it.

Frank Field : I'll mark the my question as answered as soon as it happened.

So my last Question to you

Can you confirm the described behavior

Especially when Tasks where created by another Workflow during the Actions "Assign a task" / "Start a task Process"

May I ask you for asking internally. Or do I have to open a support case to obtain an official answer

Frank - this seems to be related to my own query:

Nintex 365 on-change workflows do not start after the item is changed by another task workflow

...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.

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.

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

Oliver,

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.

• Workflow W1 on List A starts Workflow W2 on List A as User B. (not sure how this person can be the workflow initiator)
• Workflow W2 starts several Task Processes
• User C receives an assigned task and must respond to it, but cannot see the original List A where the item started from.

Here is a thought.

• User A creates a new item on List A(custom list). This starts Workflow W1 on List A.
• Workflow W1 on List A copies the item to a new (custom list) item in List B where all users have access
• When a list item is created via the workflow that starts Workflow W2 that is used to create the Task Processes.
• User B, User C and whomever else is assigned can now see the data from List A and respond to the task because they have permissions.

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​

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:

1. Create a custom list workflow (WF1) that triggers on item creation
2. Create a workflow (WF2) on the Workflow Tasks list that triggers on item creation
3. Within WF1, add a "Assign Task" or "Start a task process" action when creates a new task on the "Workflow Tasks" list.
4. Notice that WF2 does not fire when new Tasks are added to the Workflow Tasks list via the other workflow.

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).