Hi All, I would like to add a member to security group.The requirement is like a logged in user can add the member which belongs to the same branch as logged in user has. If a user has branch Mumbai, he can add the member which also belongs to mumbai branch in the group. Appreciate your help. Thanks

By definition you are talking about groups which are defined by "explicit" (not "dynamic") membership. If you consider the specific scenario where you have a group per branch, where any member of that group can add other members to that group, then this should be achievable using the "relative to resource" style MPR, using the "ExplicitMember" as the attribute ... Try this: Create a set of "All Branch Groups" - some thought will be required how you do this, as you will need some sort of subset of "All Groups" ... one way to achieve this is to extend the Group schema and include a new reference type binding (say masterResourceID) and use this to define a "branch group" (i.e. /Group[masterResourceID=/Set[ObjectID='<guid of set of all branches>']/ComputedMember]) Create a new MPR "Branch Group members can add new group members" of type "Request" For Requestors, select the "Relative to resource" option, and enter "explicitmember" (translates to "Manually-managed Membership") Select operations "Add..." and "Remove..." Turn the "grants permission" checkbox ON Use the set defined in step #1 as both the "before" and "after" set Select the "Select specific attributes" option, and specify "explicitmember" as the only attribute (optional) Associate an appropriate AuthZ workflow for group membership authorization I appreciate this may be only a specific case of a broader requirement, but I hope it demonstrates how you use the FIM delegation model, specifically with the group schema. If you wanted to extend this scenario to a more general principle where membership admin for ANY group (not just a group tied to a single branch) can be delegated in this way, then you would probably need to create another Group binding (multi-value reference attribute) and populate this with all the users for a given branch - then use this as your "relative to resource" attribute. However this is most likely going to be unwieldy. Another option (assuming there is some sort of "branchID" reference attribute binding on Person, referencing a Branch object) might be to create a search scope like this: /Person[branchID=/Person[ObjectID='%LoginID%']/branchID] ... this will show you all people at your branch. This search scope (together with an appropriate set and grants rights MPR) can then be used to restrict the Edit Group RCDC to limit the selection of group membership to just those at your branch. I haven't tried this myself, but this is an extension of an idea from an earlier post this week.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