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

Parents
  • 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!
Reply
  • 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!
Children
No Data