I’m currently looking for this behavior : The property for a user to have an account in AD, AS400 or other resource is symbolized by attributes attached to the user. For example on the user object, the attribute attAD take the value « yes » or « no ». If the value is « yes » the user account will be provisioned in AD. This is the same logic for all other resource attributes. When a user is created, a mail is sent to the top manager for approval. If the top manager refuses, all the request is rejected and the user is not created. If the top manager accepts, a mail is sent for approval to each resource manager for which the corresponding attribute is « yes ». If a resource manager accepts the corresponding attribute is « yes ». If a resource manager refuses, the corresponding attribute is set to « no ». The process continues and the request is not rejected. When the workflow is terminated, the user is created with the right attributes. The problem : The key sentence is «The process continues and the request is not rejected». When the top manager validates the user creation, if only one of the resource managers refuses, all the request is rejected and the user is not created. A user contains a lot of these attributes (about 100) Is it only possible ? Does anyone have a solution to make it work ? thank you in advance !

I can imagine 2 solutions: 1. user object is created on a FIM portal without an account. Once object is created an MPR with custom action is trigged. This custom action should do several modifications with user account (one in a time) or request to add a user to several groups. This would raise several independent approval workflows. Another MPR should watch user attributes and/or membership to construct an account name. 2. have one approval for user creation process but approval from resource manager must be raised by a custom action in authZ stage so it will look like a sub approval to original request and will not affect original workflow but will modify its workflow data. anyway, I can't imagine all of this without custom WFs.

Hello and thank you for taking the time to discuss a solution. The synchronisation uses the user attributes and doesn’t use groups. I have understood that a user creation is represented in FIM by a single request. As soon as the authz stage is validated, the user object is physically created in FIM database as a resource. That means the user object attributes are potentially in an unstable state. For example the AttAd attribute is true although the user is waiting for a validation. It can be confusing for the customer and the synchonisation could use unstable values. We could consider to reset the corresponding attribute to « no » in an action WF but we also manage the attribute modification with a MPR and I think we are going to infinite loops… The second solution you propose is much more our needs. Is it possible to disable attributes modifications/creations before the Action stage according to an approval result ?

Is it possible to disable attributes modifications/creations before the Action stage according to an approval result ? Sure, create a set that will include all 'incomplete' objects and another set with 'approved' objects. Apply an MPR which allows modification to the second set. But you can't modify user object on a portal before it will be approved - its not created yet. BUT! MS says that Authz WFs should never modify objects - seems like it would be better to modify //WorkflowData/AttAd during AuthZ phase and then have an action WF to alter user attributes.

Thanks, I am also studying the possibility of using filters and groups in this situation. I think it could be an interesting way to resolve my problem. I'm looking for this behavior : 1) The property for a user to have an account in AD, AS400 or other resource is symbolized by attributes attached to the user 2) I create a group for each resource (AD_Group, AS400_Group). All users in the set will be provisionned to the corresponding resource 3) I define a criteria based filter foreach of these groups. An user will be automatically added to the group if the corresponding attribute is true (for example a user with AttAd = true will be automatically added to the AD_Group). In the same way, a user will automatically leave the group if the corresponding attribute is false. 4) I define a MPR on the transition In event and transition out event where an approval is asked to the resource manager to enter or leave the group. 5) The top manager only validates the global user creation or modification. All is ok except if a resource manager rejects the request for a user to enter or leave a group. I think the corresponding attributes keep the old « yes » or « no » value ? I can imagine a custom activity that inverse the attribute value during the authz stage. As you said it’s not a good practice but in this way, if the user’s request to enter or leave the group is rejected, the corresponding attribute keeps the good value. Finally in the action stage, I set the attribute to the right value (« true » if the user has entered the set, false otherwise). I’m relatively new with FIM management. Please tell me if there is something wrong with this solution. Thanks again for your help !

Make it more simple: 1. user is created on a FIM portal without any additional attributes set. 2. "top manager" validates and approves a request 3. after approval has been completed an MPR starts an action activity that submits several object modification requests using UpdateResourceActivity to enable user options like ADAccount, AS400, ADLS account, Solaris shell login or whatever. this MPR can be trigged by a Transion Set IN or even by an original user creation MPR. 4. every modification for user attributes like ADAccount or AS400Account have its own MPR with its own workflow and different approvers. 5. once user will be approved for having an account in AD with ADAccount=true property it will fall into the set 'AD enabled users' and this in turn will trigger an MPR with Transition IN rule to apply proper sync rules and calculate user account name.

I have read this post : http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/b5f20a76-04a4-4783-b343-5525de2ac39c/ It seems that a request submitted by a fim activity cannot trigger an authorization workflow. I understand that when the user creation MPR uses UpdateResourceActivity in the action stage, the approval for the attribute modification will not be trigged. In this situation, I think the approval from resource managers will be skipped when a user is created. If each attribute has its own modification MPR, I think we fall in the case I want to avoid. After the user creation, if few user’s attributes are modified in the same time and if one of the approvals fails, all the modification request fails.

Hi Alexis! The problem you have is that the Approval activity fails the whole workflow silently without an exception that can be caught on a single rejection but the Forum User Phil - CGI has examined the Approval activity and found a way to make the approval activity not to fail on rejection. I'm not sure Microsoft would consider the solution supported but at least it's a way to solve your problem. Have a look at this post: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/649f6a28-f662-4296-a222-a0ebaf3dc63d //HenrikHenrik Nilsson, ILM/FIM MVP Blog: http://www.idmcrisis.com Company: Cortego (http://www.cortego.se)

Hi Alexis, You do not want an approval workflow to fire on the FIM MA Activity. I would create an ACTION workflow for new users that - as Evginy suggested - set each one of the attributes to true (ADAccount, AS400, ADLSAccount). The activities in this ACTION workflow should be done by an Actor that requires approval from the mid-level managers. In this way, each entitlement can be independently approved or denied without impacting the other entitlements. -Jeremy