Hi, I have the following scenario, in which attribute flow precedence doesn't seem to be working as it should: Background: I have 3 MAs: 1) FIM MA, 2) AD MA, 3) HR ECMA (file-based import, call-based export) The 'First Name' attribute exists in in all 3 MAs. I have sync rules set up for import and export for the AD MA and HR ECMA, and have configured attribute flow for the FIM MA from within the Sync Manager. Attribute flow precedence for the firstName MV attribute is set to equal precedence, and (not that it should make a difference), the order is displayed as 1) FIM MA, 2) HR ECMA, 3) AD MA Problem: When I make a change to the person's first name in the FIM Portal, then do a Full Import on the FIM MA, it doesn't indicate, as expected, that there is a pending Outbound synchronization for the AD MA and HR ECMA. If I locate the object in the metaverse (using the Sync Manager), it holds the correctly changed value, and also shows that there are connectors for that person in each of the connected data sources. When I do a sync Preview on the person, 1) The Import Attribute Flow shows that the change to the First Name is 'Applied' 2) Under Connector Updates, a) the FIM connector export attribute flow shows that the First Name attribute is 'Skipped: Not Precedent', and the new First Name is the 'Initial Value'. This makes sense because it is importing this attribute from FIM to the MV, and doesn't need to export it to FIM b) the AD connector shows the the new First Name is 'Not Applied', despite there being no current value in AD for First Name. (Initial Value is empty) c) the HR ECMA connector also shows that the new First Name is 'Not Applied' So, the next time I do a full sync on the HR MA, it shows that there is a pending outbound sync for FIM to change the First Name back to the original value; it seems that the HR MA is taking precedence, despite FIM being the last contributor of a value for the First Name attribute. So as previously mentioned, the attribute flow precedence doesn't seem to be working as expected. Any ideas why this might be? Thanks, Mark

Skipped: Not Precedent means that your system is not aware of an equal precedence configuration.As a sanity check, you could generate a report of your precedence configuration by using FIMOV and post it here.If the report also indicates an equal precedence configuration that is not applied, your only option is to open a support case.Cheers,Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for your reply Markus, I managed to solve the problem; when I checked the Provisioning tab on the user in question, the EREs listed showed their status as "Pending" which raised a flag to me. After a bit of investigation, I found that the FIM Management Agent attribute flow was missing import and export entries for ExpectedRulesList and DetectedRulesList. I thought these attribute flows were automatically added when the MA is created, but I guess either they weren't automatically added, or they somehow were removed. Naturally, after adding these flows, things started acting as expected. Cheers, Mark

Just an added note, I had similar 'skipped: not precedent' problems with a reference attribute which referred to a custom schema object type. It was causing strange things to happen regarding deleting the reference values from the connected data source. What I ended up doing to resolve this part of the problem was to remove the attribute from the associated sync rule and adding it to the attribute flows in the synchronization manager. After doing that and doing a full sync, everything seemed to work as expected. I then changed it back to the way it was, re-adding the attribute to the sync rule, and removing it from the attribute flow in the sync manager. I have no idea why this worked, but I would guess that it was some kind of corruption in the sync rule. Either way, I just wanted to update this, just in case it helps someone else with a similar problem. Mark

Thanks for sharing, Mark.Cheers,MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation