I can see why workflows run under the Nintex App account. The Nintex app notices a change in the item and in turn manually kicks off the workflow.
But this has some disadvantages and may cause problems.
List items and documents that are updated by the workflow will be "changed by" the app account instead of the initiator. But the initiator workflow context variable has the user that caused the workflow to start. So when i log the value of the initiator variable in the history log it shows the person that initiated the workflow.
Another issue is that the App account doesn't have enough rights to read members of a group. Sure, i can fix this by lowering the security on that group but we don't always want that.
Anyone else ran into this? I'm curious to know if there are workarounds and if there are other issues that we should take into account.
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.
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.