Exercise 5.5 - Processing Events

The Portal supports a workflow around the Events to ensure that all Events are being considered and that all Events are subject to a final sign-off.

This means that before the migration goes live, all Events should either be resolved, so they no longer occur or be accepted. Accepting an Event means actively acknowledging that the Event occurs and that this is acceptable when going live.

In this exercise, we will look at how to use the Event Editor to:

• Change the User State
• Delegate the Event processing to Partition Users
• Comment events
• Mark Events as derived from other Events

Note that the Event Editor is different depending on whether you are a Team user or a Partition User (for the Training exercises, you are a Team user)

The exercise is rooted in the Event I0022 Interest {0} with default rate {1} has been created on the Business Object Customer. To edit the event, click Edit... in the context menu.

Event Editor

The Event Editor shows static information from the Event itself that cannot be modified:

• ItemId, Business Object Name, and the Event Message
• The Event Severity and Area
• The Counts and baseline delta

The Event Editor is different depending on whether you are a Team User or a Partition User.

Team User

You are a Team User and have access to All partitions. This is the Event Editor as you see it when you have selected the All partition.

Initially, you can select a team user to be the Anchor for this Event. Unfortunately, in your Training setup, there is only you on the team. 

Next, you decide how this Event should be processed, namely the migration team must handle it - or if you want to delegate it to the Partition User(s).

Not delegated

In the screenshot above, the Event is not delegated (no check in the Delegate box). This means that you - as a Team User - can set the State and also decide if this Event is derived (caused by) another Event.

Delegated

If, on the other hand - you decide to delegate the Event, you can not longer set the State nor make the event derived from another.

Instead, you can see - read only - the user and state set by users for each Partition in the migration.

Discussion

On the discussion tab, you can have a conversion and assist others in the resolution of the Event.

History

Finally, on the History tab, you have a complete history of everything that happened for this Event - when and by whom.

this includes edits done by the Portal, when counts are changed during Publish, and also if State is set to Regression by the Portal.

What happened here?

In this exercise, you saw how the Event Editor allows Team and Partition Users to collaborate on the resolution and sign-off on Events. The end goal is to ensure that all Events are processed and either resolved or accepted before go-live.

The Event Editor behaves differently for Team and Partition Users and for each again differently depending on whether the Level is Team or Delegate.

In these last 3 exercises, we have presented the Portal, in the next exercise you get the chance to try it out by processing the Events that occurred during the Card migration.