We recently had an issue whereby various Business Processes started silently failing. They would complete, having processed 0 records, when there were actually records to process. After a lot of digging, and recreating apparently corrupted processes, it turned out that the user account which owned the processes, had had its system administrator rights revoked, and that this caused the processes to fail. However, they should have generated errors, not silently failed.
Processes affected were of the following types:
Post To GL Process For Basic GL
Generate Payments Process
Recurring Gift Status Update Business Process
Correspondence Process
Global Change Process (most, but not all)
Acknowledgement Process
Some other processes were not affected, specifically:
Receipting Process
Import Process
Export Process
Queue Process
Assign Letters Process
Commit Multiple Batches Process
Constituency Refresh Process
This problem caused us an enormous amount of stress and additional work, as our revenue processing and communication with supporters were seriously degraded, and, most importantly, we had no idea which of our many hundreds of processes were failing, or why. It is often legitimate for our processes to process 0 records, so the only way we could determine which processes were failing was to painstakingly go through hundreds of them and analyse whether they should have been processing more than 0 records, or create test records and see if they were processed.
Organization Name (Please enter full organization name) | The Wilderness Society Ltd (Australia) |
Reported Version | 4.0 |
P.S. I agree about not all organisations restricting Business Process Ownership to Administrators, but there's a chance that any solution which surfaced a deep error about being unable to access records would work for other users.
Dear Nicola,
Thanks for opening this up for voting. Our need isn't urgent, as we are, we hope, unlikely to be caught by this again, given various other steps we've taken, but we want to try to avoid other organisations going through this pain (and completely eliminate the chance of it happening to us again).
Yes, you couldn't just rely on a zero result, as that is very often legitimate. You'd need to look deeper into the processes. It may be that there is an exception or error occurring somewhere lower down when the system tries to access the records. It also seems very odd to us that it is the user account which owns the process which causes the problem, rather than the account which is running the process. The running user can run the Query and see results, so why does this not happen when the Business Process runs it? (I think the problem only occurs for Business Processes which use a Selection from an Ad-hoc Query, although I'm not absolutely sure about that.)
Kind regards,
David.
Hi David, the challenge here is how would the system know to alert if the Business process completes successfully? It may be valid that there are processes with zero records. Additionally, not all organizations restrict Business Process Ownership to Administrators. We will take this under consideration, however you might be best to pursue this as a customization if your need is urgent.
Dear Nicola,
Thanks but that's not really the point. An organisation has to know about this problem in order to do that. We were very badly burnt by this and are very unlikely to be caught by it again, but we are trying to avoid other organisations being so badly affected.
Also, that KB article is irrelevant to the situation we had, where the Business Processes 'completed successfully', so wouldn't have triggered such an Email Alert. The problem was that they actually failed to work, not that they generated exceptions. So, I do not believe that the capability I'm suggesting already exists. Please reconsider.
Kind regards,
David.
You should be able to avoid a similar situation by setting up a custom email alert for when business processes fail that incorporates the owners permission information. Please refer to KB tip 97550.