I'm using FIM for password reset only and i'm trying to get email notifications going with [//Target/DisplayName] which works ok, but i'd also like to insert the data if the password reset was successful or not.. I've added in a notification in the password reset workflow, then created my own email template.. the email does contain the proper displayname as i stated above, but whats the command to insert the result of that workflow? is there a list of commands anywhere? thanks!

Take a look at this article on the subject first. In the example there is reference to WorkflowData variables, the naming of which is entirely up to the implemementer ... so to answer your question there cannot be a difinitive list (apart from what's available on //Target and //Requester). The variables that you have at your disposal are best explored using the function evaluator in a workflow activity (use the Lookup button to see what collections you have available to you - use this to get the names of all the bindings at your disposal). In your case the //Target object is a Person object and therefore what you have available to you for inclusion in your email at the very minimum is [//Target/<personBinding>], for example [//Target/AccountName]. You also have other data that is present as an XML string within the Request object itself, but you would need to use a custom activity to extract this first to the WorkflowData collection (search this forum for the code to do this if you wish) before you are able to reference [//WorkflowData/<yourVariableName>] in your email template. Note that if you have a notification firing as the last step in your workflow, this activity will only fire if the previous activities were successful ... so the notification itself is enough to confirm success :). In your case you are looking for a success status of the workflow ... which is indeed an attribute on the Request object, but is not something you can reference in your email template without resorting to a custom activity ... however there are other ways to look at this ... e.g. what I am doing in a similar scenario (not the OOTB pwd reset workflow, but a custom one for administrators) is to check for the presence of a DRE against the person, since I have an EAF for pwdLastSet firing at the same time which I have marked with an existence test.Bob Bradley, www.unifysolutions.net (FIMBob?)

thanks for the reply, i have a better understanding now and it looks like i'll have to do some reading !