I wanting to use the FIM portal to allow user to select a valid email alias. As the user selects their profile, they navigate to a tab called email. When then click the tab, they can see a list of possible email aliases available. Can anyone help me understand how to develop a tab the FIM portal that displays email alias to users and then allows them to choose the alias? I really don't know much about the RCDC and how to develop this functionality. Any help in the right direction would be appreciated. aldean69

Before you start to look at the various UI components that you need to throw at your problem, the question you need to solve first is what is it exactly that will determine the values you want to display for selection? The UI alone will only allow you to select from a constrained set that is either hard-coded in the RCDC or derived from data present in the FIM db for the object (person) in context. This is obviously going to be an inhibitor for you, as it means you can't derive data "on the fly" as such - it generally needs to be persisted in the FIM database before it can be retrieved. I take it from your description that only existing users will be able to select an alias ... i.e. you are not trying to derive an alias at the same time as creating a new person object(?) In that case, I suggest you may want to look at using a custom multi-value string binding on each user ... call it "PotentialEmailAliases" or similar ... and populate this using a workflow that fires on either the creation of a person in FIM, or a person set transition (into the set of all persons without an email alias) - to ensure that no person without an email alias will ever exist in FIM without a (calculated) set of options. If you think that this idea might work for you, create the new binding and manually populate it for a few people ... and then use it along with an appropriate RCDC control (e.g. UocDropDownList) to see if that achieves what you want. Only when you are comfortable that this will work for you should you start to consider how to calculate this field ... as this may involve writing a custom activity, and you wouldn't want to go to the effort of building this only to find that the RCDC doesn't cut it. Lastly, before you go down the path of writing a custom workflow activity to build this property (which can be cleared out once it has been used), experiment with the Function Evaluator and see if you can use this to write to [//Target/PotentialEmailAliases] first.Bob Bradley (FIMBob!) ... now using Event Broker 3.0 @ http://www.unifysolutions.net/ourSolutions.cfm?solution=event for just-in-time delivery of FIM 2010 policy via the sync engine

Bob, Thanks again! This sounds like exactly what I want to do. I will have to derive this based on the user. The good thing is that I am not creating any person objects. I actually have a 2nd FIM instance that deals with management of the person objects. The portal I am using was originally positioned for group management alone, but now I have requirements to allow users to manage their non-HR specific data. However, I will be pushing this data back to our HR staging database to tie the alias to the user. aldean69