Hi. I'm trying to send an email after e.g. user's last name is changed and I want to show the old and the new values in email like this: "Your name was Kim Westwood , now it's Kim Eastwood ." I have tried to use [//RequestParameter/AllChangesActionTable] but it just shows the new value. How do I do this? Thanks.

You would need to create a custom workflow activity that would enumerate all changes in the request and then use the ReadResource activity to read the old value(s) from each attribute and return them as a workflow variable.Eric

Hi Hartwal,You can achieve this by using following, <p class="MsoNormal"><b>Request details:</b></p> <p class="MsoNormal"> <table style="width: 80%"> <tr class="HeadingStyle"> <td>Attribute</td> <td>Old Value</td> <td>New Value</td> </tr> [//RequestParameter/AllChangesAuthorizationTable] </table> </p> Thanks,Sri

I once tried [//RequestParameter/AllChangesAuthorizationTable] and it just rendered the new value 2 times. If I understand it right, this would work if the workflow type is authorization. My workflow is action so i guessed that [//RequestParameter/AllChangesAction Table] would be correct but it just shows the new value. Does it work correctly and what is the difference between these two anyway?

This notiifcation should be in AuthZ phase for old value and new value to be displayed correctly. By the action phase changes would have already been made on the object and hence both the columns have same data.Try having this notiifcation in the AuthZ phase of MPR.Thanks,Sri

I tried this and it seems that if I change user's attributes in portal, it works. However, if I change user's attributes in connected system (CSV in my case), it updates the attribute but does not send the email at all (if workflow type is action, it sends the message). I have noticed that if I change user's attributes in portal (and workflow type is authorization), it popups a "pending approval" window (so is some kind of approval still required and it cannot do it if the updates come from connected systems)

When updates are from connected system, they are executed in context of FIMServiceAccount. FIMService account bypasses AuthZ phase and hence emails are not sent out.The error message appears because this is in AuthZ phase. Error message is misleading and will be improved in later releases. But you don't need an approval needed.Thanks,Sri

So, if I understand correctly: 1) If I use authorization workflow, it bypasses the hole workflow and does not send emails (when updates come from connected system) 2) If I use action workflow it cannot show old values, because in this phase changes are already made and thus there are no more old values So, there is no way to do this without a custom activity?

I can't test your case for now because because my VHD is not accessible for this week, but if I remember correctly, the authz is execute if you reimport from MV to Fim Portal.For exemple, if I reimport a group from AD to MV then export to FIM Portal, a authz workflow call 'Group Validation' is launch to test validity of the group against schema.So, in your case, the workflow is a notification workflow with Target as the recipient and the email template contains the details in the 1st reply of Sri.If it launch for change in portal directly and not when reimport from MV, check the MPR to verify the Requestors if it contains the Buil-In Synchronization Engine.

You would need to create a custom workflow activity that would enumerate all changes in the request and then use the ReadResource activity to read the old value(s) from each attribute and return them as a workflow variable. Eric Eric, could you explain this ReadResource activity a little bit more. We understood that ReadResource activity would return just the current value. When the activity is executed the value has already been changed to new. We thought that the way to aproach this issue is to read requests one by one and this way find out what is the previous value.

You would need to do this in an Authorization stage. At that point, the value is not yet changed. If you do it in the Action stage, then the update wold have been committed to the FIM resource.Eric

I'm still strugling with this We managed to do this with a custom activity that reads the old values from requests. The down side of this aproach is that there is the request retention policy that deletes requests older that 30 days (default). And again, I can't use authorization workflow because the changes comes from connected system. Has anyone managed to do this? Is this even possible?

So am I correct in understanding that you are trying to catch changes that the Synchronization Service is sending in? If so then the previous method won't work as the Sync Service account skips AuthN & AuthZ activities. Is this just for a specific or a few attributes? if so, then you can either write an XMA to use the Web Service Client to set those attributes with a non-Sync Service account.Eric

Thanks for your quick reply. You're correct, I'm trying to catch changes that the Synchronization Service is sending in. And as Sri said earlier, I cannot use AuthZ workflows because AuthZ workflows are skipped. There are at least ten attributes. Can you explain this method a little bit more? As I understand it, I would leave the handling of all those attributes to this XMA (instead of declarative provisioning).

Actually, I though of an easier method. 1) Flow the AD import from the Sync sevice to a new attribute, proposedLastName. In the workflow triggered by the import. 2) Send the email notification using proposedLastName and LastName 3) Use the Function control to copy the proposedLastName to LastName Target: [//Target/LastName] Source: Trim([//Target/proposedLastName]) Eric

Thanks for replying. While this might be a solution, I don't know if it's a very practical one, because (correct me, if I'm wrong) It would double the number of attributes I thought earlier something like this myself: I could do an extra attributes for the old values (OldLastName...) Update them after notifications But this would double the number of attributes.

Are you looking to build a notification system or an audit system? From you earlier comments, it sounded like you only wanted specific attributes. To do audit, you either need to: 1) Catch the imports into the sync engine in the Import Attribute Flows 2) Build or Buy a FIM Reporting Package like Omada that reads the request history 3) You can write an Extensible MA (http://www.microsoft.com/downloads/details.aspx?FamilyID=11fb01bc-94a9-4404-bb90-ceca1a206e32&displaylang=en) to send attributre updates to FIM using the FIM Client on Codeplex (http://fim2010client.codeplex.com/SourceControl/list/changesets) that would by processed by AuthZ activities where both old and new states exist.Eric

Thanks for replying. I'm looking for solution only for notifications. And yes, this is for specific attributes and not for all, but threre are still 10 or so attributes (some are default attributes like names and some are custom attributes), and because of that, building or buying an external repository for request would be overkill for this task

If you are generating the notifications out of FIM, then it's either the "shadow attribute" method, catch and email in an import attribute flow or write an extensible MA to send the changes in a differente security context. Those are the easiest without getting into heavier dev work.Eric

Hi Hartwal, I have a similar requirement, if the user's department changes then I need to notify the old and new values in an email to the manager. Can you please share your solution.. some code sample of the custom activity will be of great help.. thanks, Krish

Hi Krish. If all you want is department, I suggest that you take a look at the shadow attribute method. Otherwise you need an external database, because you can't get those values from fim.