We have been dealing with many issues based on deactivated user accounts lately.

Chris over 9 years ago

We have been dealing with many issues based on deactivated user accounts lately. With a large company, long process life (required) and many contract employees, this is a frequent scenario. We typically receive errors similar to the one below - bringing the user account back to active status does not resolve the issue and we haven't been able to figure any way around these other than just telling customers to cancel the request and submit a new one - which is not a very good user experience.

"The user [user.name] does not have sufficient privileges to perform the requested action because they are not in any role. (APNX-1-4188-001)"

How is everyone else handling deactivated initiator accounts - since some functionality cannot be coded around (functions/expressions running under pp!initiator context, etc)? More sub processes - put almost all functionality in a sub proecss run under the designer account vs the initiator? Unfortunately after migr...

Discussion posts and replies are publicly visible

0 Chris over 9 years ago

...ating from Appian 6.6 to 7.3 we've noticed more functionality running under the initiator account, and redesigning our big, long-lived applications will not be a short or medium term solution. Thanks!
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Carlos Santander
A Score Level 2
over 9 years ago

Make sure you use a System Admin or "Deployer" account that is not tied to a specific person, so that you know it won't get deactivated. Use this account to import your applications.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Chris over 9 years ago

Hi Carlos, the issue is mainly user input tasks where expressions are evaluated under the pp!initiator context (which we cannot change) - we have been ok with system tasks as all are runing under system admin 'designer' permissions. Those are fine when the initiator is deactivated, however in that case our forms display as:
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Chris over 9 years ago

In the case above, even when we reactivate the account and restart the user input task, the form still displays with the same errors.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 mjmallet over 9 years ago

We had that same issue here as well and found a work around. With our Publishing and Translation process (for example) when it is started, we take the name of the pp!initiator and we save it to a process variable (pv!initiator). We use the process variable in the whole process and if we have sub-process, we pass it along, and we made sure to use "Run as whoever designed this process model" in our assignments.. and we deploy using the Administrator account. So if person X started the task and then leaves the company.. the team uses the quick task, assigns a new pv!initiator and all the information is changed. Of course it doesn't change the real initiator.. but at least the process can run along without having to leave person X's account active. :)
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Chris over 9 years ago

Thanks, we have been going toward a similar method for new process development - definitely best practice. Our only issue now is 30+ legacy production processes, some very high use (25,000+ processes/year), with user input tasks all over the parent process, and initiator accounts frequently becoming deactivated :(
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 mjmallet over 9 years ago

so you still have process instances that are still active using an older version of your process?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Chris over 9 years ago

Well we have not had time to upgrade all older process models yet, so while we're heading toward this method in new process model design, we will have potentially hundreds of thousands of requests initiated in the older process models before we can afford time to re-work those.. Then whenever an initiator leaves the company, we run into these issues..
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 mjmallet over 9 years ago

Yeah we are in the same situation.. we have lots of process instances that needs to be updated.. which we will have to use the Process Upgrade Plugin from AppianForum, but that's a big project to itself...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 rachealv537 over 9 years ago

I figured out a workaround. I was also having problems with this. I now know the best practice is to use a separate Appian Admin type of account to avoid this in the future. However, that didn’t help me for the processes that had already been affected. I had process nodes that where set to run as process designer. We deactivated the process creator in our dev because the person left. When we reactivated them, it still gave an error. So what I did was I created an application patch for each application with a problem. I added the process models in question. I exported them. Then I re-imported them to the same environment under the generic account. This made each model have the new generic account as the process designer. It worked. If you have a lot of models, I would suggest splitting this up into smaller patches. There may be a better way to do this but this worked for me.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel