Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


There is usually one request and one execution record for each operation. E.g. the request record contains the delta that assigns role to a user. The execution record will also contain that delta but it may additional deltas, e.g. deltas for adding new accounts implied by the role. In some cases there may be several execution records for a single request record. This happens if the execution happens in several waves. E.g. a role is assigned to a user. Some of the accounts implied by the role may be created immediately and others needs to wait for an approval. Therefore the accounts that can be created immediately will be audited in a first execution audit record. The second batch of accounts will be audited when they are later approved and created. This goes to the second audit record. This situation may also happen even if there are no approvals, e.g. in case of resource dependencies or even complex inbound-outbound-template interactions.

Event Outcomes

The result of the executed operation. All the possible values are described in the following table.

Event OutcomeOutcome DB IDDecritption

Used when operation and sub operations finish successfully. The operation is completed and the result is final.


Used when operation finish successfully, but minor problem occurred. For example operation code recovered
from some error and after that operation finished successfully. The operation is completed and the result is final.


Used when operation contains at least one operation witch status SUCCESS/WARNING and at least one
operation with status FATAL_ERROR.  The operation is completed and the result is final.


Used when operation didn't finish correctly. The operation is completed and the result is final.


Result does not make any sense for the operation. This is useful in cases that the operation is not supported
(e.g. an optional part of the interface). This is different than UNKNOWN, as in this case we really know that it
result is not applicable. In UNKNOWN case we know nothing. The operation is completed and the result is final.


The operation is being executed. This is set for operations that are executed asynchronously or take a significant
amount of time. Short synchronous operations do not need to set this status, they may go well with the default
UNKNOWN status. The operation is in progress and the final result is not yet known.


No information about operation is present. Presence of this status usually means programming bug, e.g. someone
forgot to set or compute appropriate operation result.


The operation didn't finish correctly but that was expected and handled. It is equivalent to success for all practical
cases except for displaying the result. But using success status for this situation might be misleading. The operation
is completed and the result is final.