Hi Pieter,

When we trigger a workflow for conditional start (or scheduled) we're able to override the initiator value to be the 'triggering user', however the actions taken by the workflow are still performed under the security context of the user (or in our case, app) who uses the API to start the workflow, which is why this is different.

Due to limitations inherent in the SPO App Model, we're not able to impersonate or act as any user in the site that we wish to, we're limited to carrying out actions as a user in certain conditions such as when someone launches the Workflow Designer application, and even then only on the same site. This means that to start a workflow outside of the normal 'Start on Item Created' etc. process like with Conditional Start (Nintex receive the notification of the event that occurred, evaluate your conditions, and trigger the workflow if required), we need to start the workflow as the 'App Identity' that you trust when you install the application.

There are possibly alternatives, I'd suggest if running the workflow as the user is important, add your use case to nintex.uservoice.com so we can evaluate it.

In the meantime, I will see if we can add some additional documentation/product info to help people with this.

Thanks,

Callum

I have this same issue.  I think I posted the exact same thing about it a few days ago.  Its a non-starter for most of my use cases, so i've had to revert back to just not using it and having multiple workflows that start, and then terminate on the first step if certain criteria arent met.  Leads to a lot of false starts that don't really do anything, but don't really have a choice unless i want to build mega monolithic workflows.

I havent tried it yet, but i think the action that is O365 Create Item you can enter user credentials and that wont look like it was created by the SharePoint App, but in my experience this action has been super slow, so there are trade offs.