Whenever the membership of a group is updated the following warning is always displayed:

One or many of the operation lists entered were not valid. Please ensure that the operation lists provided currently exist

The pending export operation doesn't repopulate the list of available MAs if validation fails.

However, this is logged as minor as validation can only fail if retry settings are invalid, as there is nothing else to configure.

Currently the implementation for the FIM Portal is essentially a listener, although it won't use a listener operation. However, it does not benefit from the checkoperation/listen operation pairing that AD/LDAP listen do.

If changes were missed for the FIM Portal listener, you'd have to wait for subsequent changes or the synchronization oplist to fire.

Consider adding a polling schedule for explicit delta-import delta syncs:

Benefits: Don't rely on synchronization oplist
Demerits: Scheduled delta imports.

What would be the value of a capability to execute operations following inactivity of FIM?

Leaving the implementation details, what this could be interesting for would be to Archive the run history following periods of inactivity;

What you would get out of that would be archives for blocks of activity, as opposed to a flat day/week; and considering the adaptive model, you would see an initiating change and then all the subsequent operations executed because of that first change.

If you dont want to save run profile history, you still need archive location. Should not be required.

Directory is saved, but is not displayed in UI.

When the service isn't running and action refresh is left running on a page (such as the Operations screen), the Event Broker layout is displayed twice (inside itself).

Possibly in the "nice to have" category, but it would definitely further improve the upgrade experience if it was possible to detect the existing service account details and show these in the installer wizard. If this is achievable I think this would be worth the effort - password as well if possible.

Although intermittent, I have observed the FIM Sync service failing to respond to a stop command, and "hang" in the "stop pending" state. I have then consistently found that when I also shut down the Event Broker service the FIM Sync service immediately responds to the stop request.

Once the symptom occurs, the remediation (restarting Event Broker service) has been successful for me in 100% of cases.

Disable workflow checkbox in FIM Event Broker Workflow would be great. Have to delete it to disable it otherwise & reimplementing is painful.