Improved sort order on operation index.

It appears to be ordered by creation date. Can this be alphabetical?

If an export run profile cannot be found for the outgoing operations, it defaults to the first run profile. It should instead default to "none" with "no schedule".

When run, the operation list will always execute the Next operation in the tree, irrespective of whether the success/error status.

The original issue was a misunderstanding on my part, the success status of "Next":

A
...B (Success: Next)
C

Would make C run, even though it isn't a sibling of B.

When modifying an Operation Lists list of operations, there are two ways to add a 'next operation'. The first is the 'New Operation' link at the very end of the list, the other is clicking the gear icon and selecting 'Add a next operation'. Both methods result in the next operation being added to the very end of the list.

Intuitively I feel that if you select the gear icon and choose to 'Add a next operation', the operation should be inserted immediatly after the operation corresponding to the gear icon/popup menu.

There would be two benefits to this
a) Adding an operation near the top of a long list would be a lot quicker
b) The logic in my mind is consistent with the 'Add child operation' which adds the child to the selected node. Given the behaviour of adding a child, I think it is fair to assume that adding a next operation would add it after the selected operation, despite this not being the case.

A work around currently is to add the new operation as a 'child' operation and to then perform a 'promote operation'. This has the effect of performing an insert, and I have found it to usually be quicker than adding a next operation and then clicking 'move operation up' numerous times (the fact the page refreshes after each move makes this cumbersome).

This effects both 3.0.X and 3.1.X.

Create an Email from ADAM plugin.

In an exclusion group, members marked as trigger members are not correctly blocking each other. Further investigation revealed that changing trigger memberships is not reflected in the operation engine configuration file. This was found attempting to add two trigger members to an exclusion group, with no normal members, and the operation list configuration for each continually switched around after repeated attempts (the first operation list would be the trigger member, then the second, then the first etc., while the other was added as a normal member)

An exclusion group with only normal members was found to be fine. The engine's handling of the above (incorrect) configuration was still found to be correct.

What is the Find button in the Logging's log file download suppose to do?

In the Logging tab,click the download hyperlink. A dialog is displayed with the following options: Find button, Save button and Cancel button. Click on Find button an Internet Explorer is opened with the following URL http://shell.windows.com/fileassoc/fileassoc.asp?Ext=csv but nothing else is displayed.

Perhaps this required MsExcel or MsOffice IE plugin to be installed? Is this a pre-requisite?

Our server is a VM and needs a new virtual NIC.
If we replace the existing NIC and MAC address, will this mean we need to re-licence the Unify components?

In Event Broker v2.x, operations and plugins could store operational information and other "hidden parameters" (such as timestamps) for later use.

As Event Broker v3.0 has no database, a new storage mechanism for this kind of information is required. It should be similiar to Identity Broker's "Stored Values Engine", except using something similiar to XML files in isolated storage rather than a database. It requires, at a minimum:

• The ability to share information amongst operations in an operation list by the loading & saving of values.
• Values to be stored and retrieved in a similar fashion to IValue in the entity value collection (strongly typed).

Other potential uses include:

• A persistent store for operational information such as the execution times of operation lists, etc.