I want to keep the display name as "firstname lastname". I don't want the person creating the user to modify the displayname, I'd like to keep it as somewhat of a constant based on what is entered for first and last names. I have it set up as an outbound AD sync rule so that AD populates the displayName correctly, but the FIM Portal does not since the user doesn't populate it. My ideal flow is 1. Create user in Portal 2. Automatically change Portal displayName to "firstname lastname" 3. Send email to approver to approve the new user. How can I populate that value before I even send an email for approval? If I can populate it before the email is sent, the email would not have a blank displayName.

Action workflow using the built-in Function Evaluator and Notification activities.http://www.wapshere.com/missmiis

I guess I'm wondering if the Notification activity can be considered an authorization step? I wasn't sure how to get an Action workflow to run before the approval/authorization step.

Oh sorry, I see. You can use the function evaluator in the authZ phase.http://www.wapshere.com/missmiis

I started to go down that path and got an error, and when I searched for help I actually found one of your old posts http://social.technet.microsoft.com/Forums/en-IE/ilm2/thread/2636126e-6e62-4d13-8959-57c7be5fd80b Did you end up creating a custom activity? I think we may need to do that to validate some of our data so that might not be a bad way to go. Though I would have thought this would be recommended as a way to automatically populate things like display name so that it removes some user error.

You can add the function evaluator activity in the same WF as the approval. If you place the activity above the approval then it will execute first. If you want the DisplayName value you generated in the approval, or more specifically in the e-mail templates used by the approval, then you should find that the update has succeeded and is available. Is this what you tried? You can always write to the dictionary but I don't think that's needed. Obviously if you want unique display names or you want to perform some extra work on the value such as removing diacritic characters, trimming, enforcing hyphens in double-barrel names, etc. then you will need a custom activity.

You can add the function evaluator activity in the same WF as the approval. If you place the activity above the approval then it will execute first. If you want the DisplayName value you generated in the approval, or more specifically in the e-mail templates used by the approval, then you should find that the update has succeeded and is available. Is this what you tried? You can always write to the dictionary but I don't think that's needed. Obviously if you want unique display names or you want to perform some extra work on the value such as removing diacritic characters, trimming, enforcing hyphens in double-barrel names, etc. then you will need a custom activity.

We'll do some validating of the fields on our own since we can't seem to do that through FIM, but for displayName we really just want a standard firstname/last name combination. I'm not sure I understand what you mean when you say the update has succeeded and is available. Do you just mean concat the values and add to displayname as an authorization step right before the approval emails? That's what I was trying when I got the error that access was denied. We are currently using the trial version - does that make a difference?

No the trial version doesn't matter. Just validate what actor is being used by the FE. I can never remember and always use the system actor in my own WF activities. It might be that the FE is using the requestor as the actor and the requestor doesn't have permissions to write displayName.

No the trial version doesn't matter. Just validate what actor is being used by the FE. I can never remember and always use the system actor in my own WF activities. It might be that the FE is using the requestor as the actor and the requestor doesn't have permissions to write displayName.

just create an action workflow to update the display name and some flag that the a new user is added build a SET based on that flag "Pending Users" do your approval and authorization logic on the new SET members and since the display name should be now a read only field; in the user add/edit form remove the textbox control of the display name by editing the Resource control display configuration (RCDC)

How would he implement approval in this scenario? I see the less palatable choice of imposing an additional attribute that a requestor must modify in order to trigger approval, i.e. an enabled bit, as an option. That is, once they're in the "pending user" set that attribute is writable. However what he is attempting makes more sense to me. There's no way of triggering approval after an activity writes a value, irrespective of the actor.

ops so true SET transition MPR can not have authorization workflow

Sorry, Again I wasn't understanding what you were doing - I thought you were trying to change the display name on an existing object. Yes that is right, you can't write the display name to an object that hasn't been created yet. However you can use the FE to write to a WorkflowData parameter which you can then reference in an Email template. So it would be possible to send the email with the correct display name, but then actually write the display name to the object in the Action phase.http://www.wapshere.com/missmiis

ops so true SET transition MPR can not have authorization workflow I thought you needed the user object to exist in the portal then approve the pending user to be provisioned to AD

ops so true SET transition MPR can not have authorization workflow I thought you needed the user object to exist in the portal then approve the pending user to be provisioned to AD

ops so true SET transition MPR can not have authorization workflow I thought you needed the user object to exist in the portal then approve the pending user to be provisioned to AD

Oh I didn't realize you could create variables in the workflow to use across the activities. I can do that and then write the actual value later on, but this way the email is more user friendly. It may not be completely ideal, but this can be my workaround until the displayName gets populated later on in the process.