Approval Workflow Issue: When two MPRs fired for Authorization and Action workflows
Hi, I configured the User Profile RCDC for self-service capabilities. Per requirement, Users should be able to update their Display Name on the FIM Portal, and that requires Manager approval. Users can also update Mobile Phone but that doesn't require any approvals. I Created two MPRs. #1. User Profile Self-service with Manager Approval (AuthZ) #2. User Profile self-service - No Approvals required (Action). I gave modify attribute permission on these MPRs and i selected only the attribute which require self-service. When the user tries to update only Mobile Phone, it worked as expected. No approvals triggered and change is committed as soon as the user submits the form. I have Action workflow for Mobile Phone update to send email notification to the requester for successful transaction. But when the user tries to update Display Name along with Mobile Phone on the same transaction, Approval process is initiated, and Mobile phone update didn't happen. When Manager approves the Display Name request, Mobile Phone gets updated. If Manager denies the Display Name request, Mobile Phone update also got denied as i don't see the changes committed. In this scenario, there are two separate MPRs and Mobile Phone update MPR doesn't have any authorization steps, then why FIM is combining these two separate requests into One and putting Authorization for Action Is it a bug in the workflow process or am i making any mistakes here... Appreciate your help!
September 25th, 2011 1:51am

That's by design because FIM sees "ONE request with two attribute changes in the same request" Just like most web app when you update your phone number and address in one shot, if you fail any validation, the changes won't be submitted. Similar idea.The FIM Password Reset Blog http://blogs.technet.com/aho/
Free Windows Admin Tool Kit Click here and download it now
September 25th, 2011 3:37am

I understand what you are looking for, but the behaviour you are seeing is because both changes are part of the same request (irrespective of the number of MPRs involved, it's always going to be in the one submit action) and therefore the same transaction - this is not a bug, but a "feature", because the AuthZ rejection has to roll back the entire request (not just a part of it). This is the way the FIM AuthZ process is architected to work ... approval or rejection of the entire request ... and therefore this must be the expectation we set with our users. This means that if you want to treat these 2 attributes independently, you need to set the expectation that they need to submit the changes separately. I think the best option you have is to use the binding description on your RCDC to warn users that any changes to this attribute will invoke an approval which could lead to the rejection of ALL other changes submitted in the same request. There really isn't any other alternative ... unless perhaps if you write your own UI which could split out your changes into separate requests automatically.Bob Bradley (FIMBob @ http://thefimteam.com/) ... now using Event Broker 3.0 @ http://www.fimeventbroker.com/ for just-in-time delivery of FIM 2010 policy via the sync engine
September 25th, 2011 3:50am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics