• State Not Answered
  • Replies 25 replies
  • Subscribers 4 subscribers
  • Views 7336 views
  • Users 0 members are here
Related Discussions
Home » Discussions » Process

Assignment for Unattended Smart Services

judym598
Certified Senior Developer
An application that has been in our TEST environment for several weeks recently generated an error (InvalidUserException) that was spawned when the process flow came to a 'Send E-Mail' node. I'm pretty certain the cause is due to the assignment on this node. I had it set to 'Run as whoever started the process' and I think it should be 'Run as whoever designed this process model', but I'm not sure why the error is only now showing up. The individual who started the process is not an administrator but has tested this process multiple times. Am I correct in assuming that the assignment for Send E-Mail, News Feed and Subprocess nodes should (always) be set to 'Run as whoever designed this process model' - which would be the application administrator (Administrator group) who updates/imports patches? When would it be set to 'Run as whoever started the process'? It seems as though that is the default. If i...

OriginalPostID-234736


Node Assignment.docx

  Discussion posts and replies are publicly visible

Parents
  • 0
    A Score Level 1
    IMO always use the "whoever designed" option and deploy to test, pre-production and live etc as a service or deployment user that won't get deactivated. That way, you'll avoid the issue of processes breaking because they are running as users that have since been deactivated or, as in your case, have had their permissions changed.

    You may still see issues in your development environment, though, as developers may be deactivated if they leave but will still own processes. This can be resolved by doing an export of all of the processes a deactivated designer owns, and then importing that package back into the same environment as a different developer.
Reply
  • 0
    A Score Level 1
    IMO always use the "whoever designed" option and deploy to test, pre-production and live etc as a service or deployment user that won't get deactivated. That way, you'll avoid the issue of processes breaking because they are running as users that have since been deactivated or, as in your case, have had their permissions changed.

    You may still see issues in your development environment, though, as developers may be deactivated if they leave but will still own processes. This can be resolved by doing an export of all of the processes a deactivated designer owns, and then importing that package back into the same environment as a different developer.
Children
No Data
© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.