Hi All, Currently I am facing one issue with process initiator deactivation

Hi All,
Currently I am facing one issue with process initiator deactivation.
The issue is, once the process initiator of the process is deactivated then all the query rules which are available in the input section of the quick tasks,user input tasks and gateway condition sections are getting crashed and giving Work Item cancelled exception which is related to deactivated user(privilege issue).
As per my knowledge rules(say query rules) that are available in the form input section,rules available in the gateway conditions are evaluated under the context of process initiator.
But in my case this process initiator has been deactivated in the middle of the process and getting privilege issues while evaluating these query rules.

I know that once this process initiator is reactivated and adding him to his groups again will resolve the problem, but I don't want to reactive him again.

Do we have any other solutions to solve this issue for the existing pro...

OriginalPostID-163907

OriginalPostID-163907

  Discussion posts and replies are publicly visible

  • ...cesses without reactivating process initiator again?.

    Thank you in advance.
  • Hi Anjanna,

    From the documentation:

    forum.appian.com/.../User_Management.html

    "When a user is deactivated, any running processes that were started by that user will pause by exception. This will not happen immediately, but is guaranteed to happen no later than the next time the application server is restarted. Additionally, process models that are configured to run as their designer will fail to run if the designer user becomes deactivated. For these reasons, Appian recommends that applications be imported using a service account of type System Administrator that will not be deactivated."

    The recommended way is to reactivate the user and complete the process and then proceed to deactivate the user (while changing any privileges as required).
  • Thank you for your response Vamshi, but in my case the above process is having a quick task that will be used to show only application process details in the custom process dashboard and this quick task will never be submitted and this should be in activate until the whole process is in active.
    And to get latest application details from DB, few query rules are used in the input section of the quick task where
    I am getting issues to evaluate these query rules under the context of this deactivated process initiator.

  • Reactivating the user and changing his email and password for security reasons would be the best way to go.
  • Thank you Eduardo, but we are looking for other approach other than reactivating the user again as we have some constraints to reactive the deactivated users.

    Please suggest if any other approach to solve this issue.
    Thank you.
  • No other options to my knowledge. If we were talking about nodes that can be changed to run as whoever designed the model then this would work by a simple process upgrade but for tasks? Unless you had a way to relaunch the process with the same data from a database or something similar I don't see how this can be solved since the initiator cannot be changed unless it becomes a new process.
  • I run into this same issue daily as well, I have at least 5-10 processes per day that I have to resume repeatedly as they move along. In some cases reactivating the initiator helps, some it does not. Future approval tasks seem to be where these processes pause after the initiator account is deactivated (mostly during escalation notices) - the tasks without query rule inputs and such can be resumed and they will continue. However in each case, inside the task any data presented with a QR will not load even after reactivating the account (for which I have daily Outlook reminders to review process statuses and deactivate again when requests have completed). My customers all have to deal with missing data on the form, and search elsewhere (process dashboard & attachments) for the information before the request can continue. This creates a major hassle for developers who have to support 10+ production applications while developing, and also creates poor end user experience.

    In the cases where the request is rejected to the initiator, the process must be restarted as a new instance - we cannot recover it at that point. Some of these processes have been through months of approvals after hours of data entry (up to 1,600 grid rows of financial data). The process is not SAIL converted yet, so there is no good way to port data (since all is in KDB) - telling the group "I'm sorry, you have to try again" is usually the only resolution.

    All we would need (although I'm not sure of the back-end work required for this) is the ability to change pp!initiator for a certain process instance - then we can have the group delegate ownership to an active employee, make the switch, resume, good to go. I submitted an enhancement request for this in 2013 (AN-39924), but apparently the issue hasn't gained enough traction to be considered in the base product yet. Also in a discussion with a more seasoned smart service / plugin developer, he did not know of any way to even customize Appian to accomplish changing the pp!initiator.

    We have over 32,000 active accounts and 72,000 deactive accounts with 30+ process models combining for almost 3,000,000 tasks completed - for a team of 5 BPM developers (who also handle all tech support). With more and more of the company's processes worked in Appian, this is a huge issue for us which comsumes more and more time each week.

    I would love to see a product enhancement to resolve this issue!
  • Also, to assist with the best practice of publishing process models with a 'System Admin' type of account (not related to a user), we've built an admin process model around the 'Republish Model as Different User' smart service that allows us to re-publish models with our Sys Admin account by just clicking a button. This is very helpful after moving models/patches to production, as we utilize SSO and can't quickly get back into our production environment with different credentials to physically republish the model.

    This doesn't solve our pp!initiator issues, but alleviates any potentials from a developer/designer becoming deactivated, while also keeping our developer's names off of documents and the like generated under the designer account within a process.

    forum.appian.com/.../
  • @Anjanna: there is a way with much effort involved in it, where ever you are having query rule calls in those task move them to a script task which you are running as designer and this will help in fetching data from database. Let me know, if this option is feasible for you.
  • This would help some scenarios for sure, but will unfortunately restrict you from utilizing up-to-date data, refreshed each time the form is viewed.