Case 1: we have a CA that prompts the user for a dozen pieces of info. A lot of formatting and cross-consistency checks must be performed on this input before the CA can proceed. If any of the checks fail, the CA displays an error notification & exits. This is bad because it then requires the user to re-input all of the data again, even if the cause was just a minor formatting error in one of the input fields.
Case 2: if I am sloppy and don't code extensive checking into the CA, some of the functions will reject badly formatted input themselves. This is good because such errors don't close the user input dialog: red error text indicating the problem is shown at the bottom of the dialog instead. The same thing happens when badly formatted or inconsistent input triggers validation rules violations. I've started intentionally dividing by zero when error conditions occur simply to avoid closing the dialog.
Case 2 is my preferred approach to handling errors as it is by far more user-friendly, but the only problem with it is that, over the course of normal usage by users, the CA will eventually exceed an internal error threshhold which puts the CA into a suspended state. I then have to disable and re-enable the CA to reset the error counter so it can be used again (and no, this task can't be automated: I've asked).
I would like to request one of the following:
1 - remove CA & WFR (workflow rule) error counters, or
2 - allow error counters to be reset in an automated way, or
3 - add a "Throw Error" action that can be used in CAs/WFRs that behave like the errors in case #1 and don't count against the error count total
Hello Lance,
I would recommend discussing this with your Account Executive Matthew Bruggen to understand your requirements better and possibly open an internal Change Request to some of these suggestions.
Thank you,
Please sign in to leave a comment.