reference a reference attribute in FIM Portal? RRS feed

  • Question

  • I'm trying to set up a manager delegate attribute in the FIM portal but I am trying to wrap my head around what I have in mind and if it is possible.  I have an MPR set up that give permission to edit certain user attributes only to the users manager as defined in the manager (reference) attribute. What I am trying to do now is set up a delegate attribute that the manager can set on their profile that gives a delegated user the same permissions on people that report to the manager in the FIM portal.  basically have an attribute on all users that references the user's manager's delegate.

    Example: User A reports to Manager B and delegates Manager C to help him.  Manager B and C both have permissions to edit User A.

    Is it possible to have a user attribute that is auto-populated based another user's attribute value? Essentially User A has an attribute "DelegatedManager" that references Manager B's attribute "DelegatedAssistant" value of Manager C.

    Thanks in advance for the help.

    Wednesday, May 1, 2013 9:04 PM

All replies

  • DaneB_85,

    I believe you'd need to use a script to populate the delegate attribute on the user object (for use with your relative to resource permission granting MPR).  You could trigger the script using a custom workflow activity that would call it when a change was made to the delegate attribute on a manager object.

    Good luck!


    Friday, May 3, 2013 2:08 PM
  • @Ryounk007

    Thanks for the help it gave me an idea and I think I have it working but need to test the performance impact ect.  Here is what I did:

    I created 2 reference attributes (DelegateManager and UsersDelegatedManager) The DelegateManager is set by the manager and UsersDelegatedManager is set by the system. 

    I created a workflow and set it to run on policy update.  It uses a custom expression function to set [//Target/UsersDelegatedManager] to a value of [//Target/Manager/DelegateManager]

    I then created a set for all users with an active status and an MPR that uses a set transition in  to trigger the workflow.  I can leave it running but it will only update users as they become active and I want to update all users on a regular basis.  So I set the MPR to disabled and used powershell to endable then disable the MPR.

    I used this as a reference: ( and created a scheduled task on the portal server to kick off the powershell script to enable then disable the MPR which triggers the run on policy update and updates all the users. It will run late at night when no one is using the portal and since I dont have very many active user objects I dont anticipate a it taking very long. 

    I have not done a full scale test yet but I confirmed it worked for updating one user.  I will test over the weekend updating more users and update my findings. 

    I did however find out that it seems that if the reference attribute [//Target/Manager/DelegateManager] has a blank value that it will not trigger and update for the user so if the manger clears his delegate field it will not clear it out but I need to do some more testing to confirm. I could probably fix this with and IIF expression.

    Its not the best solution but it will work untill I can spend some time and build a script to update users.



    • Edited by DaneB_85 Friday, May 3, 2013 11:29 PM
    Friday, May 3, 2013 11:26 PM
  • Seems you can't update a reference type to null... so it's possible that when it reads the [//Target/Manager/DelegateManager], it detects that it's null and doesn't update.

    Thinking about how you've got it... you basically want the delegated manager to have the same access as the actual manager, right? That means, every time you create an MPR referencing the manager, you also have to create an MPR referencing the UsersDelegatedManager... right?

    That seems like a bit of overhead to me, both from performance and managability... what I would do is have BOTH the manager and the delegated manager stored in the UsersDelegatedManager field - and then you only need one set of MPRs.

    The upshot of this is that you could change your workflow from:

    [//Target/UsersDelegatedManager] = [//Target/Manager/DelegateManager]


    [//Target/UsersDelegatedManager] = [//Target/Manager/DelegateManager] + [//Target/Manager]

    This would then solve your problem, because as long as the user has a manager attribute, the UsersDelegatedManager will be updated.

    Of course, you may run into the same problem if the user's Manager access gets cleared (they'll still have access via the MPRs on UsersDelegatedManager). You may need to use a custom workflow activity here.

    - Ross Currie | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services

    Wednesday, May 8, 2013 4:11 PM