Process Models have an Alert setting that does not follow best practices

Question

My health check report indicates that I have the following problem to solve: "276 process models have an alert setting that does not follow best practices. All models should have explicit custom settings to alert the appropriate business support group and should not explicitly reference users." 
 I have 459, and as far as i know most of them are configurated this way: 
 
 And also this warning in all the proceses configurated this way: 
 
 1. Is this the problem? Should I set all of them with custom settings > Send to group? 2. Maybe I only have part o them like this, and the other 276 processes are configurated to Send alert to an specific User and I only have to change those ones? 3.Or Maybe is there any other place where I can set alarms, for example in specific nodes? Since the picture is General Properties of the Whole Process Model. 
 
 Thank you so much!

GopalK · Accepted Answer

HI, The way your process model is configured now , its default by Appian. You must select "Custom error alert" option and then either you can use expression rule to decide the targeted group or people or you can just use fourth option where you can specify any group or user.

Mike Schmitt · Answer

Yes, that's the cause of this "problem". Really though, it's only as much of an "problem" insofar as how much you care about it. If you don't care about it, you can ignore it. 
 However it's not a very convenient configuration because it ends up emailing alerts to everyone in your system who happens to have an Admin-level account, which on almost any setup is not a good idea - hence the best practices recommendation. 
 I strongly recommend NOT simply pointing them to a group. You would at LEAST set up a constant (pointing to a recipients group) and point them to this, by way of the "send to this expression" configuration. 
 However I also recommend NOT to simply use a constant for that, because in any large system you MAY run into cases where you want to disable or alter alert recipients for certain process models sometime in the future. So what i *actually* recommend is one further step of complexity in the initial setup (which is NOT all that complex all-in-all)... 
 Basically, you will declare an expression rule (a unique one for each unique "app" or top-level differentiation in your system, at least if you have more than one); have the expression rule capture some nominal parameters including initiator and pmId, and call *that* in the "by expression" configuration in all your process models, similar to what's seen here: 
 Inside the expression rule, at least at first, you can simply call your app-specific "Process Alert Recipients" group (by constant); but the nice flexibility here is that if you find need to refine the recipients group for any particular process model (even including already-running instances) in the future, you can add logic within the expression rule to look for specific PM Ids and send any alerts for those PM(s) to a different audience. 
 I actually had to do this once so far in my production instance when an overnight automated report generator got a little too alert-happy a few months ago, and some of the higher-up stakeholders got tired of getting alerts for it (but still wanted to be in on alerts for other things). e.g.

Mike Schmitt · Answer

FYI if it's an emergency and you really know what you're doing , it also might be possible to export all the process models, [edit: i'll go ahead and remove the unsupported methodology]

Mike Schmitt · Answer

Cool, that sounds good then - hopefully it goes by quickly

Mike Schmitt · Answer

I know of no faster way than by opening them, editing the alert setting, and pasting the expression code in the expression editor. You can at least make that last part of it more expedient by keeping the code in your clipboard buffer (i actually have a text file in notepad++ with the snippet handy for new process models so I don't have to constantly re-type it).

Process Models have an Alert setting that does not follow best practices

Top Replies