If the SQL Server agent fails validation, its title becomes:

Create Unify.EventBroker.Agent.SQLServer,Unify.EventBroker.Agent.SQLServer

This is not the case for any of the other agents, not even the Oracle DB Agent.

When I login to the event broker I'm redirected to http://localhost:8080/Error/Unauthorized with an error message:
Sorry, you do not have permission to perform this action.

I tried the fim admin and the fim event broker service account and I'm still getting the error. I've also restarted the service and still I got the error. I've reinstall the program restarted the service and I still got the same error.

Currently, I'm stuck. Any help is appreciated

The statistics object is displayed, not its message value.

The service unavailable page link that should go back to the home page, instead fails as it contains the area of "Framework".

Missing hidden for agent id for pending export operation.

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.