I extended the schema with a new object type, like the group object.The object hasmultiple approver/escalator attributesto enable approval from different management dimensions:* line management [ approver | escalator ]* role management [ approver | escalator ]*security office[ approver | escalator ]* ...I want to create separate authorization workflows for each business dimension using the 'approval' activity.However I cannot validate //Target/LineManagementApprover and alike.Is the approver attribute checked against the Approval Object? When I have an approver attribute on my custom object then I can get a workflow going using //Target/Approver. Do I have to add the additional attributes also to the Approval Object? If so how will they be propagated from my custom object to the approval object?

John,I am not entirely certain where you are going with this but here is my first crack at it:Are you complaining that you can't validate LineManagementApprover when some modifies that attribute on the likeagroup object or when someone modifies the member attribute?If the former then setup an MPR that triggers when someone modifies the LineManagmentApprover attribute and then have an authorization workflow that validates the new value.If the latter then setup an MPR that triggers when someone modifies the member attribute and have three or more authorization workflows one for line mgmt, one for role mgmt, one for security office etc.You shouldn't need to modify the approval object schema or the actual objects. What happens when a request is submitted is well defined in the SDK documentation. But to summarize, it identifies the applicableMPRs, thenit checks permissions (assigned via MPRs) and processes Authentication workflows (if any) assigned by the applicable MPRs, and then process the Authorization workflows (if any) assigned by the applicable MPRs, then the action happens and then it processes any action workflows that have been assigned by the applicable MPRS.For each authorization workflow (or for each suitable authorization workflow activity) an approval object will be created. The responses are created as ApprovalResponse objects recording the accept or reject. So the magic for getting the approvals to the right place is in the workflow or workflow activities. You can setup one of the built in authorization workflow activities to send approval emails to people based on reference attributes in the target object.David Lundell www.ilmBestPractices.com

David, @ first txs for having interest in this issue.The problem is using the policies and workflows in general. We have things running in that respect. We only have to implement a scheme that goes beyond the approval scheme contained in the FIM/Portal and FIM/Platform. So just an aprover and escalator are not adequate for our solution.For me it just that I can not select/validate the extra attributes.

Is the issue that you can't use the attributes in filters if so check out Brad Turner's post onhttp://www.identitychaos.com/2008/11/ilm-2-rc0-access-denied-when-adding.htmlDavid Lundell www.ilmBestPractices.com

I figured it out, I just had to select advanced view and then modify the XOML directly!