Hi again, I am trying to write an MPR that will be called when a request titled 'Create ApprovalResponse: <request info> Request' is created. I have noticed that these requests contain useful information about a request, such as the approver, which I am trying to gather. For now I'm just trying to send a notification email (via workflow) to prove that the MPR has run. To test I try creating a new DG, approving it, and then check under 'Search Requests' and observe the associated requests that appear. The 'Create ApprovalResponse: blahblah' request appears each time but my MPR does not pick it up. I have tried configuring my MPR a few different ways, it currently looks like this: MPR type: Request Requestors: All people Operation: Create Grants permission: No Target resource definition after request: (I have a set defined here that contains all requests with "Create: ApprovalResponse" in the displayname) Resource attributes: All attributes Policy workflows: Here my email notification workflow is called. Any ideas? Thanks :)

At one point it no longer became possible to have request objects trigger MPR's on their own, but I don't recall if that is no longer the case. I remember back in one of the early beta's attempting to wire up some policies that would alert the Administrators any time a WF terminated with an exception, but it just wasn't possible. Eihab brings up a good point, but I'd need to try it and see if works now. An alternative would be to insert your notification activity after the Approval activity in each of your WF. This works because the very next step of the WF is on hold until the Approval is completed, so it would look like so: Approval->Notification The only downside to this approach is that you need to modify all WF that have approval steps and insert your notification activity. If you are after Approval data relative to the object, I can dig up my RCDC extension that does that. I basically setup an Approvals tab in the Group object (or custom objects even) that display all relative approvals to this object which allows you to see who approved them. Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Hi, I think your requester is not All People. There is a resource named "Forefront Identity Manager Service Account". Create a set for that resource and use it as a requester. Eihab

Ok, as promised: http://www.identitychaos.com/2011/03/fim-2010-adding-approval-tab-to-your.htmlBrad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Ok, as promised: http://www.identitychaos.com/2011/03/fim-2010-adding-approval-tab-to-your.html Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.] Got a screenshot for the blog post? ;)My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Ahh, I will post the RCDC for Approvals today if I can, but what might make more sense is to create a policy that reacts to the creation of ApprovalResponse objects. In those objects you will have: Creator Created Time Link to the Approval object Decision status (approved, pending) Reason Requestor You should only need to chase the Approval object if you need to determine what the threshold was on the overall action. For instance, if you needed to know that 2 approvals were required, you'd need to pull that out of the Approval object versus the ApprovalResponse object. So, to summarize, you could: Use the existing Set of "All Approval Responses" Create a WF containing your Notification activity Create an MPR wired to "All People", Transition-In to "All Approval Responses", execute your WF That would be enough to trigger an email for every approval response.Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Hi, I think your requester is not All People. There is a resource named "Forefront Identity Manager Service Account". Create a set for that resource and use it as a requester. Eihab Thanks, tried that but no go. Good suggestion though :)

At one point it no longer became possible to have request objects trigger MPR's on their own, but I don't recall if that is no longer the case. I remember back in one of the early beta's attempting to wire up some policies that would alert the Administrators any time a WF terminated with an exception, but it just wasn't possible. Eihab brings up a good point, but I'd need to try it and see if works now. An alternative would be to insert your notification activity after the Approval activity in each of your WF. This works because the very next step of the WF is on hold until the Approval is completed, so it would look like so: Approval->Notification The only downside to this approach is that you need to modify all WF that have approval steps and insert your notification activity. If you are after Approval data relative to the object, I can dig up my RCDC extension that does that. I basically setup an Approvals tab in the Group object (or custom objects even) that display all relative approvals to this object which allows you to see who approved them. Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.] Thanks Brad, that RCDC extension sounds interesting :). To explain, basically I am trying to address our audit requirements. For every request that is processed I need to capture the following data which must then be available to auditors for 7 years: -Who requested it -Date/time -Individual who approved it (we only need one approval) -Full details of the request, i.e. for new groups-- name of group, list of members, for group join/leaves-- names that were added/removed I'm only worried about group management for now. We have an existing help desk system that I can email this audit info to and store it there indefinitely, removing the need for FIM to store it. All I need is a convenient way to get all the above info into one email :). When I noticed those 'Create ApprovalResponse' requests which have a lot of the above covered, I thought I might be onto something. But it seems the MPR will not fire when these appear :). I'm not sure how others are addressing audit/logging. The ideal solution for us would be getting all details into one email and sending it on to our helpdesk system at some point in the workflow. So as suggested I can send that notification after the approval in the workflow, and updated the workflows to include this is not a problem, but am not sure how to actually include all the needed info.

Added one to Wiki post here: How Do I Add The Approval Reporting Tab to the Group RCDCBrad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Added one to Wiki post here: How Do I Add The Approval Reporting Tab to the Group RCDC Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.] This is fantastic, thanks very much. It's very close to a complete solution for my problem. The only thing missing is the actual details of the requests. I.e. though this tab I can see that several updates were made to my test group, but I cannot see who was added/removed, only that several updates of some kind were made and approved by my approver. Any ideas on adding this information in? I can see that it is not present in the 'Approval' or 'ApprovalResponse' requests. It does appear in the 'Update Group' requests when I search all requests but I'm not sure how to reference that. I can click on the 'Update to Group: X Request' link in the 'All Approval Requests' list, and wonder if the missing info could appear here as it does when I view the version of the 'Update to Group' request that was created by the approver in the 'Search Requests' area.

If you add "Request" to the list of attributes in the ColumnsTODisplay property then you'll at least have a link to the parent request object, but I don't see a way to display that information in this view without borrowing some items from the Request RCDC. I've been meaning to try this but haven't had a chance to yet. Basically, if you look at a given Request object, the RCDC there will take apart the Request Status Details and present the table to you. I'm wondering if its possible to do something like this by leveraging this little bit of XML (stylesheet code not shown) <my:Control my:Name="RequestStatusDetail" my:TypeName="UocHtmlSummary" my:Caption="%SYMBOL_RequestStatusDetailCaption_END%" my:Description="{Binding Source=schema, Path=RequestStatusDetail.Description}" my:RightsLevel="{Binding Source=rights, Path=RequestStatusDetail}"> <my:Properties> <my:Property my:Name="ModificationsXml" my:Value="{Binding Source=requestStatus, Path=DeltaXml , Mode=OneWay}"/> <my:Property my:Name="TransformXsl" my:Value="{Binding Source=RequestStatusTransformXsl, Path=/, Mode=OneWay}"/> </my:Properties> </my:Control> This is taken out of the Request RCDC. In order to see what you want to see you'd need to take apart the RequestStatusDetail XML like this does.Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

If you add "Request" to the list of attributes in the ColumnsTODisplay property then you'll at least have a link to the parent request object, but I don't see a way to display that information in this view without borrowing some items from the Request RCDC. I've been meaning to try this but haven't had a chance to yet. Basically, if you look at a given Request object, the RCDC there will take apart the Request Status Details and present the table to you. I'm wondering if its possible to do something like this by leveraging this little bit of XML (stylesheet code not shown) <my:Control my:Name="RequestStatusDetail" my:TypeName="UocHtmlSummary" my:Caption="%SYMBOL_RequestStatusDetailCaption_END%" my:Description="{Binding Source=schema, Path=RequestStatusDetail.Description}" my:RightsLevel="{Binding Source=rights, Path=RequestStatusDetail}"> <my:Properties> <my:Property my:Name="ModificationsXml" my:Value="{Binding Source=requestStatus, Path=DeltaXml , Mode=OneWay}"/> <my:Property my:Name="TransformXsl" my:Value="{Binding Source=RequestStatusTransformXsl, Path=/, Mode=OneWay}"/> </my:Properties> </my:Control> This is taken out of the Request RCDC. In order to see what you want to see you'd need to take apart the RequestStatusDetail XML like this does. Brad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.] Thanks, that is unreal! Adding 'Request' to the list of attributes shown covers what I am after, doesn't matter if extra clicks are needed as this is just for admins and only if the audit trail needs to be checked. Now I will work on increasing the data retention setting a little, maybe to 90 days, and exporting the requests to some sort of text dump before the requests are cleared out. Thanks very much for all the assistance. I might play with borrowing from the Request RCDC as you suggested to perhaps get it all on the one screen. I've also finally managed to get that MPR to fire when ApprovalResponse requests are created-- using a transition MPR instead of a request MPR seemed to do the trick :)

Newbie, Have you found how to increase the data retention beyond the default 30 days and if so, how? I'm referring to a way other than changing the SystemResource Retention configuration. Basically, does FIM keep the data in the database, but not searchable or available on the Search Requests page? If so, how does one get access to the historical data to match an auditors requirement by law of say....5 years.

Newbie, Have you found how to increase the data retention beyond the default 30 days and if so, how? I'm referring to a way other than changing the SystemResource Retention configuration. Basically, does FIM keep the data in the database, but not searchable or available on the Search Requests page? If so, how does one get access to the historical data to match an auditors requirement by law of say....5 years.

In Administration | All Objects | System Resource Retention Configuration object. On this object you can change the default setting from 30, but only if you add an MPR granting Administrators the rights to do so. This is an older article, but still describes the process: http://www.identitychaos.com/2009/11/fim-2010-rc11-adjusting-request-object.htmlBrad Turner - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Newbie, Have you found how to increase the data retention beyond the default 30 days and if so, how? I'm referring to a way other than changing the SystemResource Retention configuration. Basically, does FIM keep the data in the database, but not searchable or available on the Search Requests page? If so, how does one get access to the historical data to match an auditors requirement by law of say....5 years. Brad, Can you speak to my second paragraph where I request if anyone has come up with a viable way of retrieving the data for auditing purposes that DOES NOT involve changing the retention configuration? And if yes, in a SQL to FIM to SQL scenario, what were the steps involved, the pitfalls of that scenario, and challenges?