As SharePoint developers, we all use the SharePoint (server) object model. If your code is executing in a Web context, i.e., in the w3wp.exe process space, you don’t have to read on.

But if you are writing server-side tools running as console/win forms applications or PowerShell scripts, you MUST be aware of the following:

• Event handlers will execute in your process space, and “who knows what these handlers do?” What permissions are required for the code to execute successfully? And worst of all, will your process be alive long enough for the event handler code to finish???

• Workflows will be triggered in your process space… See above for all of the caveats. Also read this blog from Yuan for more info about this topic.

I’m almost at a point where I think it is completely unsafe to write any sort of code similar to what I describe above if you can’t ensure that your code WON’T trigger ANY event handlers/workflows written a third party.

Microsoft states that the code must be executing under an administrator account and I wouldn’t try to tweak this since we don’t know anything about the third-party code that will be executing. In theory though, I don’t see how it won’t be enough to be running as an account member of the WSS_ADMIN_WPG group. But anything LESS than this won’t work UNLESS you know EVERYTHING about ANY code that might execute.

If you don’t know what events/workflows will be triggered, I would strongly advise you to use the Web Services / client-side object model instead. Now events and workflows will be executing in w3wp.exe.