Regarding unattended Node assignment

Certified Associate Developer

Scenario: The user started the process and before process completes  user  left the bank .The sub process got errored because  assignment of  nodes is 'run as whoever started the process'. In this scenario , do we need to change assignment of that node to 'run as designer of  the process'. in the production and restart the instance , or any other Approach?

  Discussion posts and replies are publicly visible

Parents
  • 0
    Certified Lead Developer

    This is something that has to be more carefully planned than most newer devs realized, when there is even the slightest chance a process instance started by a user will ever outlive their active status.

    However unlike in the older days, there's currently a reasonable work-around in case it does happen, particularly if a deactivated user is the initator of longer-lived instance that needs to stay active (and not breaking) for whatever reason.  Note that this workaround is only remedial, it shouldn't be something your process is initially designed for (but instead should be designed to avoid the need for this...)

    Take the deactivated user account - reactivate it, but then rename it (particularly the username) to something indicating that they're a deactivated user.  Then I'll usually change the "last name" field from whatever it was, to "Service Account".  Then add it to the Service Accounts system group (and remove the email address associated with the account).  This both prevents the account from ever auto-deactivating, while 100% preventing the original owner of the account from getting back into it.

Reply
  • 0
    Certified Lead Developer

    This is something that has to be more carefully planned than most newer devs realized, when there is even the slightest chance a process instance started by a user will ever outlive their active status.

    However unlike in the older days, there's currently a reasonable work-around in case it does happen, particularly if a deactivated user is the initator of longer-lived instance that needs to stay active (and not breaking) for whatever reason.  Note that this workaround is only remedial, it shouldn't be something your process is initially designed for (but instead should be designed to avoid the need for this...)

    Take the deactivated user account - reactivate it, but then rename it (particularly the username) to something indicating that they're a deactivated user.  Then I'll usually change the "last name" field from whatever it was, to "Service Account".  Then add it to the Service Accounts system group (and remove the email address associated with the account).  This both prevents the account from ever auto-deactivating, while 100% preventing the original owner of the account from getting back into it.

Children
No Data