Hi all I have scenario where i will allow only the manager and assistant to edit few attribute which in turn will trigger some script.If some other user is trying to edit user profile,it should trigger a mail to that user saying that he is not authorised person to edit and the value he is trying to edit should be set to already existing value.I am new to custom activity. Your Guidance will help me to proceed furuther. Thanks in Advance Hira.hima

Good news - you don't need a custom activity here ... all standard OOTB functionality: Create an MPR "Custom: Managers can change selected attributes" as follows: relative to resource: manager grants rights: TRUE before set: All People after set: All People attributes: <selected attributes> workflows: none (unless by "some script" you mean there to be "some workflow") Create an MPR "Custom: Assistants can change selected attributes" as follows: relative to resource: assistant grants rights: TRUE before set: All People after set: All People attributes: <selected attributes> workflows: none Ensure that no other MPR is granting rights to all people to edit your attributes Ensure your Edit User RCDC has the my:RightsLevel XML attribute specified correctly for ALL your selected attributes from the above MPRs - e.g. my:RightsLevel="{Binding Source=rights, Path=Description} - this will ensure that these attributes are READ ONLY except for the manager or an assistant. Note that this way you don't need any email notifications ... people just only have access to edit the attributes they are allowed to.Bob Bradley, www.unifysolutions.net (FIMBob?)

Thanks for your suggestion. Still i have few doubts,in my scenario the assistant of that particular manager can edit the user details not all the assistant.how to differentiate the assistant attribute? Thanks in Advance Hirahima

The only way to do this I think would be to have another user binding "manager assistant" (custom reference attribute), since the "relative to resource" idea only works relative to the resource in context (i.e. in this case an attribute of that user).Bob Bradley, www.unifysolutions.net (FIMBob?)

The only way to do this I think would be to have another user binding "manager assistant" (custom reference attribute), since the "relative to resource" idea only works relative to the resource in context (i.e. in this case an attribute of that user).Bob Bradley, www.unifysolutions.net (FIMBob?)

Hi Bob "The only way to do this I think would be to have another user binding "manager assistant" (custom reference attribute)"--I need clarity on this line of statement. Thanks and Regards Hira hima

Well ... let's say you have the standard single-value refererence attribute of a user called "assistant" populated for a person's manager, then you need to give both of these users the same access. In FIM terms, for the user in context, this would be both manager and manager/assistant. Since you can't put manager/assistant in the "Relative to attribute" field of the MPR you need something new that is replicated from this ... say managerAssistant. It would be cool if FIM could support the concept of say a "virtual attribute" (much like the AD user virtual attribute "memberOf" for group memberships is really the inverse of the group\member relationship) ... but while it doesn't you will have to manage the replication yourself ... e.g. using the FIM sync engine. I suggest you extend the FIM user schema and try this for yourself and prove it works ... then work out how you are going to sync it :)Bob Bradley, www.unifysolutions.net (FIMBob?)