One user has multiple Employee Types. How to setup a Management Agent and createILM Portal account to accomodate such a joined key?

Hi Alexander, Could you provide some more details on what you are trying to do? What do you mean by "joined key", just a multi-valued attribute? Be aware that you cannot set as anchor a multi-valued attribute... Cheers, Paolo

Thank you for your reply. Here is the situation:One Employee withEmployeeID = 1234 is hired in the company in two positions Part-time Employee and Part-time Contrustor. In SQL I have two tables one for employee infromation and another one for Employee positions with some information related to the position. It is possible that Emloyee with two positions have two different active directory accounts. The active directory accounts could be in two different domains or same domain, depending on the position type.I am not sure how to create an ILM Portal account. Does that mean that I have to create two accouts? How to set up Synchranization rules and management agents to provision the active directory accounts?

Hi Alexander, There are several possibilities: 1) create a cartesian join among the "employee_information" and "employee_position" tables and use EmployeeID + position as anchor attributes. Then you export an account to ILM for each position. 2) create only one person in ILM, with a multi-valued attribute "positions". I think that in any case it might be convenient to have more than one outbound synchronization rule. You could create a set "people where position contains <Part-time employee>" and another "people where position contains <contractor>". Then you create two outbound rules, one to provision employee accounts and the other to provision contractor accounts, using the two different sets in the "target resource definition after request" field of the Management Policy Rules. Try to experiment with the different scenarios, and see which one is more suitable for you. Probably having only one person is more elegant because you avoid data duplication in the portal, while the multiple persons solution is easier to maintain (since you want to create several accounts). Hope this helps, Paolo

Hi Alexander This is a big subject, but here are something you might do/consider. The simplest approach would be to treat the person as two identities in the synchronization engine and portal. In the sync engine you could flow a constant into an emplyeeType attribute (and out to the portal). You could create two provisioning sync rules in the portal that are triggered by different MPRs that use sets whose membership is determined by the employee type. This really only works if the person can really be treated as two identities for instance 1. if does not matter a search for Alexander Ratas in the portal would find two people, 2. or if Alexander has a self-service mobile telephone number in the portal, they will have to update it in two places, 3. or if an HR says this person has been sacked, they have to remember to disable the contractor account as well The more complex approach is to join the two objects into the synchronization engine, you will need to find a good join e.g. mark the contractor table with the employee number, however I have always found it difficult to persuade directory owners to reliably do this, and if they dont, then you are back to the simple case above with two identities as they will both (presumably) project when a join fails. Assuming you have managed to do this, you can then either merge any duplicate attributes into a multi-value attribute in the Metaverse using the new equal-precedence feature or flow them into their own attribute (e.g. employeeID, contractorID) For other attributes, you will have to decide where the precedence lies, e.g. do you trust the last name from HR more than the one entered into the contractor system? Any inbound attributes from AD will also be more complex, typically this willbe their email address which you will flow out to the portal for any approval workflow I think a custom flow would be simpler for this, but you could do it with a number of codeless sync rules and MPRs that cover all of the combination i.e. employee only, contractor only, employee and contractor. You also need to consider which account would be used to access the portal and populate the mail, mailalias and domain attributes as appropriate. Because you cannot use a custom flow into the portal, this means that the MV attributes wil have to be populated by custom/codeless import flow from the directories. As the previous post suggests, try out the scenarios I think I would go for the simple one first and see if can meet the business requirements, the second option is going to be complex to implement and might be difficult to support.Regards Steve Mitchell Technical Director - Oxford Computer Group

Thank you for you replys Steve and Pablo.I was wandering, If I use multivalue attribute for employeetype, then I probaly have to use mutivalue attribute for the email address also.Ifemployee typeis a multivalue attribute How can I display allits values to the user in the ILM Portal Work Info tab in the EmployeeType dropdown list?

Hi Alexander, to change the way an object is displayed you can refer to these documents: http://technet.microsoft.com/en-us/library/cc678642(WS.10).aspx http://technet.microsoft.com/en-us/library/cc678639.aspx If you want to modify the ILM schema, it's probably easier to add one or more new multi-valued attributes and bind them to the Person object rather than modifying existing ones. Check the ILM 2 schema guide at http://technet.microsoft.com/en-us/library/cc561137(WS.10).aspx . Cheers, Paolo

Thank you Paolo for all your help,At this stage I will tryto create an ILM account for every Employee + position.Later I wil try the customization.