That is more or less what we do in our non-production environments where we don't want most user receiving email as results of testing. We don't have a separate form though. That is a more elegant solution. We just add a field to the User form.
If somebody is whitelisted for email their User record has 'Can Receive Email' is set to Yes. On the AR System Email Messages form we have three filters. 1. Gets the value of Can Receive Email from the User form (this could be any form) where To: = Email Address 2. If it is No or NULL the second filter adds the To: field to the end of the Subject (so we know where it was supposed to go) and changes the To: to a shared email box my team has access to (and the subject shows who would have received the email). 3. Similar to filter #2 but for CC: and BCC: Since this is at the Email Engine level it is in effect for all ARS apps. [image: Inline image 1] On Fri, Sep 27, 2013 at 8:46 AM, Longwing, Lj <[email protected]> wrote: > ** > Ray, > I don't know if there is any way around this other than to have the user > NOT be in the position to receive the emails...meaning that they shouldn't > be in the group, assignment, etc, whatever is causing the system to try to > notify them....if they don't want the notification, then they shouldn't be > in the position to be sent it. > > FYI...just thought of a possible 'custom' workaround for this. > > Create a form that contains a list of 'don't send' > users/addresses....maybe even auto-fed by the people form with the user > going 'offline' (that's entirely up to you)....but have workflow on the > email form that fires on submit, have it check to, cc, bcc for any > references to any of the users in question, and strip that value out of the > outgoing email, and then possibly, check to see if the 'stripping' caused > all of the destination fields to become blank, and then set the 'Send' flag > to 'No'....this would effectively eliminate any scenarios where those users > receive email from the system :) > > > On Fri, Sep 27, 2013 at 9:37 AM, Ray Gellenbeck > <[email protected]>wrote: > >> ** >> If you re-read the details, the email address values were already blanked >> out. Similarly, workflow ignores default notification mechanism if you set >> the notify action to "email" instead of "default." >> >> More important was the point that... >> >> a. The ars email engine has a peculiar way of creating and addressing >> messages that will result in emails going out in this case even though the >> email address field is $NULL$ >> b. The email engine totally ignores CTM:People settings of Status as >> well as User settings of Disabled/Enabled and Default Notification in this >> case. >> >> Ray >> >> ------------------------------ >> *From:* Vyom Labs Support <[email protected]> >> *To:* [email protected] >> *Sent:* Friday, September 27, 2013 6:32 AM >> *Subject:* Re: Notifications firing unexpectedly - Odd case >> >> Hi, >> >> We can overcome this by enabling the option "None" for the field "Default >> Notify Mechanism" on the "User" form and By setting the "Email Address" as >> blank on "CTM:People" form. >> >> Please find attached screen shots in this regards. >> >> -- >> Regards, >> Nitesh Kumar >> >> Vyom Labs Pvt. Ltd. >> BSM Solutions & Services || ITIL Consulting & Training >> Email: [hidden email] || Web Site: www.vyomlabs.com Follow Vyom Labs >> http://twitter.com/#!/vyomlabs >> || http://www.linkedin.com/company/vyom-labs >> -----Original Message----- >> From: Action Request System discussion list(ARSList) [mailto: >> [email protected]] On Behalf Of Ray Gellenbeck >> Sent: Thursday, September 26, 2013 11:42 PM >> To: [email protected] >> Subject: Notifications firing unexpectedly - Odd case >> >> I have ITSM installed but have customer workflow installed. At one >> point, all members of a given group are sent a email notification via >> filter. >> >> An unexpected behavior happens. >> >> Details (this is tricky, so read carefully) >> 7.6.04 server (Remedy OnDemand system, not that it matters except to >> describe underlying components/config) >> >> Each person's UserID/login is their email address (for SSO purposes, we >> use the full email address for their ID to allow the solution to be >> accessible by all our domains). >> >> Example, my login ID would be Raymond.Gellenbeck@(domain).sony.com >> >> ODD BEHAVIOR (PROBLEM): >> If the person's profile in CTM:People is set to "Offline" and their >> actual "E-Mail Address" field is blank, they still get an email sent via >> the workflow. >> >> ***NOT*** what was expected nor desired. >> >> More detail and theory on why this happens: >> >> Setting someone to Offline in CTM:People does NOT set their User record's >> "Status" field to "Disabled". >> >> The ARS Email engine is getting the command from the filter to email this >> group, then creating a record for each group member. >> >> For each message record, it then checks that person's CTM:People record's >> email address field and changes the "to" value from the UserID to email >> address if it finds a value. It does not skip records set to "Offline". >> Alternately, it may be checking the User table instead. >> >> Regardless of where it checks, if it fails to find a value for email >> address, it leaves the UserID in place and attempts to send. >> >> I tested this theory by creating a new group member (bigbob, for >> example). The test member record has no value for email address and the >> userID is not a valid email address. >> >> Sure enough, the email engine fills in the value bigbob, then fails to >> find an email address and attempts to send the message to just "bigbob" and >> results in the attempt record being set to "error" instead of "sent". >> >> So, I guess the point is, do NOT think that just setting a person to >> "Offline" will prevent them from getting email messages if you use this >> naming convention for loginID's. >> >> To explain, we use this scheme so that all domains can participate in >> using the change management tool and the microsoft-side team decided they >> wanted to use this scheme rather than the "(domain)\(domainID)" format. >> >> Replies are welcome that clarify the source(s) the email engine checks >> and what the rules are regarding status and when to ignore a >> person/record. Thanks in advance. >> >> Raymond H. Gellenbeck >> Manager | Business Service Management >> Sony Network Entertainment >> P: 858.207.1563 | M: 619.500.3993 >> E: [email protected] >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
<<image.png>>
