can we have variables in the notification mails we send ? like the list of new users or smthn like that ? or is just plain text ?Hitch Bardawil

Sure you can - you can include tokens like [//Target/Manager] or [//Requestor/DisplayName] ... i.e. any bindings on the target or requestor. You can also include [//Delta/...] but that is probably xml that will need transforming. Then of course you can write anything you like to WorkflowData and access it using[//WorkflowData/...]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

You can reference certain parameters from the workflow which is triggering the notification. Here's a basic template on how to include some user information: FIM: Send Password Expiration Notifications But you can also "chase" referential information: like resolving manager of a given user. That example is fairly simple. Sending a list of new users seem harder to achive: new since when? On the other hand sending a mail for each new user is definately a possibility. Could you clarify more to what you are trying to achieve?http://setspn.blogspot.com

i've set up a user creation approval workflow where users need a variable set to true before they are exported to my AD what i need to do now is inform a set of administrators that there are X new users in the portal that need your approval so my notification email gets sent whenever a user transitions in the all people Set (through an MPR of course) and i'd like to put those peoples' display names in my email Hitch Bardawil

thanks bob this however is new to me... what do you mean by workflowdata ? where do i find it ? Hitch Bardawil

I'm not sure how you'll go trying to do that on a set transition MPR ... FIM tends to want to send a notification per request, so that should be achievable, but the "text book" notification model is using a request MPR (per user), fired on a CREATE. If you persue the set transition idea, you may find you'll be forced down the path of using custom activities to set up something in the WorkflowData collection that you can then reference in your email. I am not expecting you to have any luck getting anything very usable using the set transition approach without having to do some extra lookups on the FIM database, because I suspect that the set transition data you're going to have will be just the user guids.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

ow i get it, i tried to use the request MPR but no MPRs get triggered when a user is created in the portal that why i switched to the transition MPR the only MPR triggered is the Synchronization: Synchronization account controls users it synchronizes Hitch Bardawil

There is no reason why you can't trigger request MPRs on changes by the Synchronization account - it's just that you're restricted to ACTION workflows (not AuthZ for instance). In your case, though, ACTION is what you want. If your MPR isn't firing you haven't defined your MPR correctly ... it WILL work for CREATE by the Synchronization Service Account ... I do this all the time myself to default values in the portal (using the Function Evaluator, for example).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

okay, my request MPR for creation had all people as requestors i need to set it to the sync service account then ! thanks! i'll try that right away ! Hitch Bardawil