What is the best way to add manager (reference attribute) to MetaVerse entry in the following situation. RRS feed

  • Question

  • We have a SQL Table of users and their managers as main source to MetaVerse.

    The table is provided by HR and gives the ids for all the INTERNAL users + managers.

    However, some of the INTERNAL users may have EXTERNAL managers and these manager ids will not exist in the Sql table as "user ids".

    In this case FIM will flow a null to manager field in the MetaVerse as it cannot find (dereference the external manger's id)

    All is not lost, all managers should have AD accounts. The manager's id not in HR table can be found in AD 99 times out of 100.

    What I want to know is the best strategy to fill in the MV manager attribute when null by getting it from AD. What confuses me is the manager being a 'reference' field. This fact may limit my options.

    What if I wrote some C# import attribute flow rule for the HR MA, is it OK just to push the DN *string* of the manager found in AD into MV:manager attribute? If not what should this C# code do??

    What is best way to cover this hole, I am sure we are not unique in this situation?

    Thursday, September 24, 2015 6:56 AM

All replies

  • Hi Harold,

    that sounds bad, but since HR has  the manager Ids of externals and set them on the users I would assume they have the data of externals somewhere in their system.
    Is there no way to get them from HR, even if you dont use them to sync attributes but best is to have them in CS and join them to MV ?

    If thats not possible you can do the following:

    1. Create some script or SSIS package to query AD for the externals

    2. add those users to the HR table you get (seperate table and create a view to merge is with HR data)

    3. having a user id and maybe another name column filled is enough

    4. have that external in MA joined but do not flow any attribute, so FIM can handle references the normal way.

    If might be easier with the attribute flows to have a extra column objectType in the table/view and give the external users a seperate objectType.

    Run that script/SSIS every time before you import data from HR to FIM

    Enumerating the accounts from AD in a attribute flow is a very time consuming thing, so I would handle that outside of FIM.


    Peter Stapf - ExpertCircle GmbH - My blog:

    Thursday, September 24, 2015 7:47 AM
  • Thank you for confirmation.

    I have decided that easiest way is for Help Desk to use the Portal and edit the user and select the correct Manager for him/her. 

    This needs a bit of housekeeping. Now, all AD accounts (internal to HR and external to HR) need to be present as users in FIM Portal. Notification error Email sent to HelpDesk when creating new AD account that has no manager attribute. Have 3 levels of ownership of manager attribute precedence: 1 HR, 2 AD, 3 FIM

    Tuesday, September 29, 2015 9:11 AM
  • Following on from what Peter says - the manager reference cannot be inserted directly into the FIM Metaverse using code - it must flow in from outside.

    Think of it like this - any two objects with a reference relationship between them must enter FIM through the same door, they then walk hand-in-hand through the Metaverse, and then exit through the same door. If at any point one object goes miising the reference is gone.

    I'm unlcear from your post where the information about the external person being a manager and who they manage actually comes from. Is this information in HR? If it is, surely they also have a representation for the external people in HR?

    Thursday, October 1, 2015 8:52 PM
  • OK. I accept that a reference attribute cannot be built from Extension code. The reference must be provided by a connected system. In my case the simplest would be the FIM Portal.

    Maybe we are expecting too much of FIM, but we were sold on the idea that FIM can work out who the manager is from an ID. If we have an *single* HR feed table with two columns one EmployeeID and the other ManagerID then FIM can figure out the details of the employee's manager by looking in the EmployeeID column using the ManagerID value. Super. But this falls down when the employee's Manager is a consultant and here is the issue.. his ID is created not by HR but by a separate system, however it is known/given to HR and is used as the ManagerID in the HR feed table. Is that clear?

    This is not problem for existing employees as as you say we can get the manager attribute from AD to MV joins. This becomes a problem only for NEW hires with a Consultant manager.  I thought the easiest way to fix this would be by code.

    Friday, November 13, 2015 8:30 AM
  • I can see at least 2 possible approaches to solving this one:

    1. Extend your HR source to include connector objects for consultants (like a UNION ALL statement in SQL) such that the manager value, when defined as a reference property, resolves to the DN of the source HR user (either consultant or permanent employee) in the same HR connector space.  This means that you can directly flow the manager property into the metaverse and out to AD as @Carol describes.
    2. Import your HR consultant ID into the metaverse as a new string "ManagerID" property and export to the FIM Portal, then use a workflow to update the manager reference property whenever this value changes.  You can then import this property back into the FIM metaverse and out to AD ... where the HR MA is precedence #1, and the FIM MA precedence #2.  You will probably run into a "skipped-not-precedent" issue here with just the FIM MA, so you may need to use the FIM Replay MA as a surrogate secondary source of manager in lieu of the FIM MA.

    The first option would be my preference, but this may not be easy depending on your selection of MA type for the HR MA (e.g. PowerShell or ECMA would be easier than say a SQL MA).

    Bob Bradley (FIMBob @ ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Proposed as answer by UNIFYBobMVP Wednesday, March 2, 2016 1:40 PM
    Sunday, February 21, 2016 6:18 AM
  • I like option 2.

    Am I understanding you correctly?

    I need a custom FIM attribute managerID and a custom MV attribute managerID.

    If I export to FIM MA managerID <-- managerID then the FIM user has an attribute managerID with his manager's employeeID in it. Ok. I can trigger workflow if/when the managerID attribute changes...

    BUT, can you explain a bit more what is meant by: "update the manager reference property"

    Wednesday, January 25, 2017 3:26 PM
  • Option 2 involves importing the manager ID into a string property in the FIM Service, and updating the native "Manager" property which is of type "reference" whenever your REQUEST MPR detects a change in this value from the SYNC SERVICE.  You may need to install the MIM WAL to access a custom workflow activity to call in your workflow.

    Bob Bradley (FIMBob @ ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    • Proposed as answer by Leo Erlandsson Monday, January 30, 2017 12:24 PM
    Thursday, January 26, 2017 10:14 PM
  • As I think your logics can work if another managers accounts (INTERNAL) also will be stored as DN in HR database.

    In normal cases in managerID cell there is something like emloyeeID which referenced to manager account, existing in the same DB.

    Better way for me it is to create employeeID for EXTERNAL managers, which can't be used for INTERNAL users and this will be working fine.


    Monday, January 30, 2017 9:35 AM
  • Yes that's an option too. My approach is the same principle, but augmenting the HR source with an EXTERNAL source (think of it like a SQL UNION statement, but without the necessity of the externals needing to be physically in the same SQL database).  PowerShell is one way of doing this and there are many others.

    Bob Bradley (FIMBob @ ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    Tuesday, January 31, 2017 3:16 AM
  • Harold - can this one be marked as resolved now?

    Bob Bradley (FIMBob @ ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    Thursday, May 24, 2018 4:35 AM
  • I'm in a similar situation.  I already have the ManagerID (his/her employeeID) out in the portal for each user.  I also have MIMWAL installed.  Do any of you have any direction on a workflow to update the Manager in the portal?  I'm assuming the Update Resource activity?

    Mike Leach |

    Thursday, February 21, 2019 7:58 PM
  • Hi Mike.  Yes you can certainly take a workflow approach to do this, but I would not recommend it as there are several shortcomings you will invariably run into at least one of them.  There are always going to be scenarios which cause your policy not to fire when it should, leaving you with a referential integrity issue to firstly detect and secondly rectify ... on a continuous basis.

    I presume the ManagerID is from an authoritative (HR?) source, in which case there is a corresponding MIM management agent.  I also presume that the ManagerID user property in this HR MA is of type string or numeric.  You need to convert this to a reference attribute instead and essentially that means constructing the value to correspond with the anchor value/dn for your HR MA.

    Once you manage to define ManagerID as a reference property it can be imported directly into the MIM Metaverse "manager" person attribute binding (which is already of type reference) and then out to AD (also a reference in the form of the AD DN).  No workflows, no mess, no risk of referential integrity problem ... unless the source data isn't flawless of course.

    Bob Bradley (FIMBob @ ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    Friday, February 22, 2019 2:21 AM
  • Hey Bob.

    Thanks for your response.  Your assumptions are correct.  The ManagerID comes from a SQL MA (HR).  I have been attempting the code extension approach.  But, I have never done a string to reference conversion.  My code just isn't working.  I was trying to convert on export to LDS.  Would it be better to convert on import from HR? 

    Mike Leach |

    Friday, February 22, 2019 2:34 PM
  • Yes 100% correct - you need to declare the data type of your source "managerid" attribute in your HR MA as type "reference".

    In order to do this, your ManagerID will have to resolve to the anchor (DN) of another object in your HR MA connector space.

    For example, here are 2 simplified HR records in CSV format:


    If instead of declaring ManagerID as type "Numeric", declare it as type "Reference".  What MIM will then do on import is try to "resolve" each referenced ID to another object in the same CS.  In the case of the first record, John can report to himself if he is the top of the manager hierarchy, and Alison reports to John.

    By setting your HR MA up this way you can import the ManagerID property with a DIRECT attribute flow to the manager property in the metaverse ... and from there a direct attribute flow to manager in your AD will work a treat.

    Bob Bradley (FIMBob @ ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    Sunday, February 24, 2019 10:39 PM
  • That sounds like it would be a perfect and easy solution to this.  In my case, the ManagerID is simply that employee's EmployeeID.  In addition, the DNs of those users in the HR MA are their EmployeeIDs.  So, simply changing the data type should take care of this?  I don't see this as a data type in SQL.  Is there more to it than just switching it?

    Mike Leach |

    Monday, February 25, 2019 2:52 PM
  • That’s all you need to do - this is the MA schema I am talking about here, not an underlying sql data type.

    Bob Bradley (FIMBob @ ... always using MIM Event Broker for just-in-time delivery of MIM 2016 policy via the sync engine, and continuous compliance for MIM/FIM.

    Monday, February 25, 2019 7:13 PM
  • Thanks Bob!  I just exported 6500 managers to LDS and 16,000 to the portal!

    Mike Leach |

    Tuesday, February 26, 2019 8:11 PM