Process Assignment .

The first. This is important! The designer of the model will always be a sys admin in the production environment. Running nodes by default as sys admin disables an important layer of security and permissions in your application.

Only run as designer if absolutely necessary!

Unknown said:

Only run as designer if absolutely necessary

This is great for transient or short-lived processes.  But many systems (regardless of how advisable this is) implement long-lived processes where the overarching parent process will be responsible for launching new subprocesses for months (or years) after its initializiation.  The issue here is, there's no way to control or mitigate who is registered as the "initiator" for the parent process, and it's inherited down through subprocesses 100% as-is.

So if this long-running instance is launched by a user who then subsequently leaves the organization - well, suddenly you have severe and not-well-explained errors all over your process instance.  Because subprocesses, rules, etc, will be trying to run under the authority of a deactivated user (and, again, there's no way to change or mitigate this within a running instance).

I know the kneejerk reaction to this is to simply toss one's hands in the air and say, "well then don't build long-lived processes!", but we both know that's not always a feasible answer, for many potential reasons.  Until we are given more granular and/or flexible controls over the "initiated by" property of subprocess calls, i'm afraid in many cases the ultimate answer will be to launch subprocesses under Designer authority.  IMHO, if your security setup is such that you're relying on the initiator-user's security to ensure against improper access, then things have not been set up correctly; this should be a last-resort fallback, not a primary method of access control to a process instance or its internal functionality.

Unknown said:

Only run as designer if absolutely necessary

This is great for transient or short-lived processes.  But many systems (regardless of how advisable this is) implement long-lived processes where the overarching parent process will be responsible for launching new subprocesses for months (or years) after its initializiation.  The issue here is, there's no way to control or mitigate who is registered as the "initiator" for the parent process, and it's inherited down through subprocesses 100% as-is.

So if this long-running instance is launched by a user who then subsequently leaves the organization - well, suddenly you have severe and not-well-explained errors all over your process instance.  Because subprocesses, rules, etc, will be trying to run under the authority of a deactivated user (and, again, there's no way to change or mitigate this within a running instance).

I know the kneejerk reaction to this is to simply toss one's hands in the air and say, "well then don't build long-lived processes!", but we both know that's not always a feasible answer, for many potential reasons.  Until we are given more granular and/or flexible controls over the "initiated by" property of subprocess calls, i'm afraid in many cases the ultimate answer will be to launch subprocesses under Designer authority.  IMHO, if your security setup is such that you're relying on the initiator-user's security to ensure against improper access, then things have not been set up correctly; this should be a last-resort fallback, not a primary method of access control to a process instance or its internal functionality.

I fully agree. In the end, there is no simple answer to this complex question.

100%

This has been my experience as well, one of those situations where, while running nodes as "whoever started the process" is best practice, it cannot always be followed.  We have some short lived processes where this is not an issue, but processes that must remain active longer must have nodes set to run as the designer - thus we do not rely on any inherent security.

We still see issues with deactivated initiator accounts even with all unattended nodes set to run as designer however.  Some functions run under the context of the initiator account no matter what, such as task escalations (our biggest culprit of these currently).  In this case when later task escalations fire it pauses the process with "ERROR: Work item cancelled".

Typically I have to edit the process instance, remove all escalations from user input tasks, restart the node.  I have built an admin mechanism based on a process report and the Process Management Services plugin to resume processes in bulk, but this only works when the user account is reactivated, which poses a security risk.

I think we have a Feature Request in from around 2012 to allow editing of the underlying pp!initiator :)