I think a lot of enterprise scenarios - especially provisioning/deprovisioning, would be a lot easier to implement if FIM handled the distinction between a person and an account better. One personmay oftenhave multiple accounts in a single system.Actions related to individual systemsshould occur onan accountobject, but HR/address etcactions should generally occur on a person object - and ALL related accounts. Relevant workflows could then work on account objects orperson objects (and recursively on all their accounts)I'd like to see separate person and account objects with reference attributes which link the account(s) to the relevant person.I realise this would require a complete redesign of the portal, so probably won't happen any time soon.

This is good feedback, Capriole, thanks for sharing.All, what do you think about this?Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

I think this idea is just about words, in some systems it's called "account" and in others "user" and this is known by everyone that it means "User account" I don't have a problem with it and I see no reason to add a default "account" resource. What I on the other hand dislike is that the words "User" and "Person" are used for the same resource type in the portal and in web services. The name of the resource is "Person" but in the portal it's called "User", I would prefer "User" to distinguish between "User account" and the physical person. //HenrikHenrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Henrik,Could you share how you'd handle this scenario- if there's abetter way to handle this with the existing classes/resources I'd like to use it.Fred Smith joins the company as a systems administrator. The company HR Systemcontains employment status,address and manager attributes for Fred SmithFred needs 3 accounts in a single AD domainfsmith01for normal usefsmith01test for testing purposesfsmith01adm foradministration purposes(A "typical" AD MA wouldhave connectors to 3 objects in the MV+FIM, A "typical"HR MA would have a connector to1 objects in the MV+FIM)When Fred changes role, hisaddress or managerdetails change, or he leaves,ALL 3 ADaccounts should be updated or disabled.I have explored ways to achieve this with multiple MAsper external system,tricky lists or custom workflows, but it would nice for it to be "easier"... and I thoughtseparating account and person objectswith a mechanism to maintain the relationship might do this...

I admit it's a tricky scenario and I get your point... :-) But!.. The number of accounts affected by this is usually low and the cost/complicity in both development of the product to handle this and training/understanding for implementors would probably be too high and with just a couple of months left for release this is nothing we could even hope for. As you said, this could be done using workflow (definitely the right place for implementing this) and instead of complicating the product even more I would appreciate a guide that helps solving this scenario instead. //HenrikHenrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

This is a common issue, even if a person only has one account in each system, they need to be handled (add/removed/disabled etc.). It could be solved by having mutiple attributes on the person (one per system/application). But this is messy and difficult to extend. One approach I am exploring for a project is to have two new object types: - a system object that contains system information such as name and a list of people who can approve an account, escalators etc.- an account object what conatins the account name in the target system, account status (enabled/disabled), a reference to the person and a reference to the systemA custom approval workflow is triggered on creation of a new account object and seeks approval from the person's manager and system approver.A custom action workflow updates all acounts owned by a person - e.g. disable all, delete all etc.Steve Mitchell Technical Director - Oxford Computer Group

Thanks Henrik/Steve A really good guide would definitely goalong way and might be better/easier than more product "features".If either of you get something suitable working it work be greatif you couldshare it.For me it's on the backburner while i get the mundane parts working...

Hi all, this scenario is interesting for me as well. I want to allow users to have multiple accounts and get some information updated in all of them when the user's data changes in the Human Resources database. I have tried this approach: - add a "owner" property to Person objects in the metaverse and in FIM - when I create a "secondary account" (i.e. a test or administrative account) for an existing user from FIM, I set the owner of the account to the EmployeeID of an existing user - create a new inbound rule for the HR MA with relationship owner = EmployeeID This, however, does not work as only the "primary" inbound synchronization rule (having a relationship EmployeeID = EmployeeID) is applied. I tried another approach, defining a new MA, called "HR Secondary", and applying the inbound rule for secondary accounts to that MA. This approach works if the user has only one secondary account; if he has more, only the first gets updated. Is there a way to specify that a synchronization rule could be applied to more than one resource in the metaverse? Capriole , you were mentioning a "multiple MAs per connected system" solution you tried, was it something similar? did you manage to get it work? Steve , when you talk about "Custom action workflow" you mean a workflow that triggers a custom activity? A custom activity would of course solve all problems, but I was wondering if there's a way to obtain this without writing custom code. Cheers, PaoloPaolo Tedesco - http://espace.cern.ch/idm

Themultiple MAs per connected systemwas to get round the fact that you can only have a single connector. So if you need N-to-1 relationships then just create N MAs, and tweak the filtering. It certainly looked technically possible this way, but pretty sure it would be unusable in the real world unless you had a single experienced person looking after it.I had other ideas involvingprovisioningaccounts from AD and people from HRbothinto an intermediate SQL databaseand probisioning FIM from a join there -but it seems slightly crazy to set up another database to managerelationships between accounts and identities when FIM is supposed to do that....Cheers.

Hi Capriole, thanks for your answer! It looks like the N-MAs option is not really feasible, at least if one wants to grant the possibility to create an arbitrary number of secondary accounts. Moreover, it has the disadvantage that you have to maintain a referential integrity between primary and secondary accounts yourself (e.g. setting the "owner" attribute to an employeeID as in my previous example), since you cannot define a relationship criteria in a synchronization rule involving a reference attribute (obviously, since references make sense only inside a single connector space). I too had thought about the join possibility and dismissed it as crazy :) I'm now trying to investigate an alternative: - when you create a secondary account, set the primary account as manager (now FIM guarantees referential integrity) - define a workflow with a Function Evaluator Activity for each attribute you want to copy, e.g. - Activity Display Name: Update First Name - Destination: [//Target/FirstName] - Value: Custom Expression -> [//Target/Manager/FirstName] But I cannot understand how to define a rule to trigger the workflow properly, i.e. whenever the manager is modified. Has someone tried something like this? Cheers, PaoloPaolo Tedesco - http://espace.cern.ch/idm

Hi All,I'm currently also investigtion into this issue, because I consider this as esentionalto an Identity Management system.My approach is to have two different object in the FIM database; user/person/people (also don't like this different names for the same resource) and accounts (where accounts could be AD, Notes or other target systems. This resouces has very few attributes, only the ones which are required to create and account and are acocunt specific, no person information.There is a 1-n realationship between person and accounts. I already have an idea how this looks in the interface.The account resources is which are provisioned/deprovisioned in AD and other systems. Through an additional MA, where the accounts in the connector space join to the metaverse person objects, the account person attributes (name, address, location and more) are flowing outbound from the MV person object to the CS objects. In this case you can have n CS object joined to 1 MV person object. This is my plan, i'm not there yet. Currently I'm struggeling with figuring out how to add addtitional objects to the FIM Service MA. Anyone could give me a hin?Regards, ChristianIAM Consultant

Hi Christian! I'm also working on a solution for this problem even thought I'm only going to add two attributes to the user object schema and my solution will either be a blog post or a short white paper bundled with a couple of workflow activities. If you wish to add your costom objects to the FIM MA you must add it to the Synchronization Filter from the portal (/Administration/All Resources/Synchronization Filter) and then update you FIM MA schema. Henrik Nilsson Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Paolo, no I have not found a way to do what I want without a custom workflow activity. We do have this working now, it did take rather a lot of code.Steve Mitchell Technical Director - Oxford Computer Group

We have solved this in a rather "non-FIM" manner by creating an XMA that reads data from the Metaverse an imports it back to to theaccount object. For example, a SQL view uses a join between the user and their accounts and providesN account objects with attributes from the user object, these account objects are imported and join to the account object in the V and flow in any global setting (such as disable account, user has left)Steve Mitchell Technical Director - Oxford Computer Group