Hi All, I'm working through setting up workflows for my FIM environment. I have a workflow where I need the system to send an e-mail to a "personal" e-mail address upon account creation (Hotmail, Gmail, Yahoo). I have this value populated in a custom schema attribute named "Persmail". When an account is provisioned to my ADDS MA I want it to send an e-mail to this personal e-mail using the address in that field. When setting up the workflow I have selected send e-mail notification and created a template. I'm aware I can type //Target and it will default to using the email attribute for the intended user. I don't want this behavior, is it acceptable to use //Target/Persmail to have it use that field instead, or is there another way I should be doing this? Thanks in advance.

That should work fine (although I've not personally tried it). By default it checks the mail attribute in target but you're overriding that by giving it an attribute name. IMHO, so long as the field contains a valid email address, it should work. If you test and it fails, push it into a workflow parameter. Thanks B

The question you are really asking is "will the default notification workflow activity work for something other than the email attribute of a FIM user identity"? In my experience I have found that this ONLY works if there is a value in the standard email attribute. Furthermore, (and this is from memory only) if you try to send an email notification explicitly to [//Target/email] the workflow actually fails ... i.e. it is expecting the notification recipient to resolve to a FIM user identity which is (a) present in AD (has an objectSID), and (b) has a valid email. Now I know that this does NOT necessarily have to be an exchange email address, but I am pretty certain the default notification activity only understands the use of the default email binding on person. So - in order to do what you want you are probably going to have to write your own "alternative email notification" custom activity ... however it would be nice to be proved wrong here :)Bob Bradley, www.unifysolutions.net (FIMBob?)

The question you are really asking is "will the default notification workflow activity work for something other than the email attribute of a FIM user identity"? In my experience I have found that this ONLY works if there is a value in the standard email attribute. Furthermore, (and this is from memory only) if you try to send an email notification explicitly to [//Target/email] the workflow actually fails ... i.e. it is expecting the notification recipient to resolve to a FIM user identity which is (a) present in AD (has an objectSID), and (b) has a valid email. Now I know that this does NOT necessarily have to be an exchange email address, but I am pretty certain the default notification activity only understands the use of the default email binding on person. So - in order to do what you want you are probably going to have to write your own "alternative email notification" custom activity ... however it would be nice to be proved wrong here :) Bob Bradley, www.unifysolutions.net (FIMBob?) This is my recollection/experience as well. I think I hacked around it by temporarily populating the mail attribute, firing the notification, and then undoing it.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

The question you are really asking is "will the default notification workflow activity work for something other than the email attribute of a FIM user identity"? In my experience I have found that this ONLY works if there is a value in the standard email attribute. Furthermore, (and this is from memory only) if you try to send an email notification explicitly to [//Target/email] the workflow actually fails ... i.e. it is expecting the notification recipient to resolve to a FIM user identity which is (a) present in AD (has an objectSID), and (b) has a valid email. Now I know that this does NOT necessarily have to be an exchange email address, but I am pretty certain the default notification activity only understands the use of the default email binding on person. So - in order to do what you want you are probably going to have to write your own "alternative email notification" custom activity ... however it would be nice to be proved wrong here :) Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Interesting. Unfortunately I need the mail field. I suppose I can do what Blain mentioned, and push it into a workflow parameter, as it does seem I can select that as a value. Anyone done it that way?

Yes pushing a value in the workflow parameter and selecting that will work, have done that already and it is working fine.Need realtime FIM synchronization? check out the new http://www.traxionsolutions.com/imsequencer that supports FIM 2010 and Omada Identity Manager real time synchronization!

The format is a comma-separated list of e-mail addresses IIRC. You can obviously push a UniqueIdentifier, UniqueIdentifier[] or List<UniqueIdentifier> too but that looks up the Email attribute as you've seen.