That is an interesting issue. It does make sense to me though. I am a fan of the email address = username when you have people that are not from your company.
What I think is happening is the people record is set to use email as the preference by default. The notification engine is going to reference that and force the notification action to be email instead of using the User Default Notify Mechanism. So their email address is NULL in the people record but wait! The Email Engine can send to just a Login Name. Well that just happens to be an email address. As you noted with bigbob the Email Engine will send to a username as entered. It will fail when trying to send a mail to bigbob but the username 'Raymond.Gellenbeck@(domain).sony.com' can validly receive email so it does. So should the Notification Engine try to send email to people that are Offline? That could be debated for and against. I am wondering does the User form still have the email address in the Email Address field? I wonder if nulling it there would help or is it really sending to the Login Name? The Disable option in the User form is just there for looks (except for a certain SSO product, thanks John for inserting your voice into my head). See (and vote on) this Idea https://communities.bmc.com/ideas/1701 if you think the Disable choice should do something. Jason On Thu, Sep 26, 2013 at 11:12 AM, Ray Gellenbeck <[email protected]>wrote: > 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"
