Workflow setup and event lists
Purpose
This page deepens the workflow area around the practical setup of error codes and event codes, plus the daily handling of open event messages. It complements the overview page with the operational steps from the legacy documentation.
Set up error codes correctly
Error codes represent the business situations that are detected by the system. Users cannot redefine these codes freely, but they can decide which messages should be treated as ignorable in the workflow.
The typical sequence is:
- Open the error codes.
- Decide per code whether the message is ignorable from a business perspective.
- Mark a message as ignorable only when no operational action is really required.
Too many ignorable errors weaken the control layer. Too few create a flood of warnings in which real critical cases disappear.
Assign event codes correctly
Event codes define which event inside the system should be monitored and how it becomes an actionable workflow message. Only when the event is assigned to a user or responsibility context does it become a process case that can really be worked on.
Always check:
- is the event code described clearly from a business perspective?
- is it clear who should react when it occurs?
- does the technical function mapping really match the expected process?
The most common project issue is not a missing code, but missing clarity about ownership. Then messages are generated, but not acted upon effectively.
Use open event messages every day
As soon as the workflow creates events, they are available per user. The messages can be opened from the role center tile or directly as a list.
For daily work, the important habits are:
- filter by open, completed, or all messages
- review the employee and team relation
- keep the number of open cases visible
- jump from the message directly into the linked process
A good routine is to review open messages at least once per day from a business perspective instead of only marking them as completed technically.
Recommended processing logic
- Filter new open messages by relevance and process area.
- Open the affected process through the link or process reference.
- Resolve the business issue or classify it consciously as tolerable.
- Only then set the completed status.
- Trace recurring cases back to setup, master data, or unclear ownership.
When the setup should be tightened
| Observation | Likely cause |
|---|---|
| too many unimportant messages | error codes are too strict or not marked as ignorable |
| critical cases remain untouched | responsibilities are not assigned clearly |
| the same message returns again and again | the master-data or process root cause was never removed |
| users know the tile but not the list | no daily routine for event monitoring exists |
Typical error patterns
| Situation | Possible cause | Check |
|---|---|---|
| users receive too many unnecessary messages | error codes were not classified properly | review error codes and ignorable logic |
| relevant messages disappear in the daily flow | open event lists are not reviewed routinely | establish role-center and list usage |
| message exists, but nobody reacts | event code has no clear responsibility | review user and team assignment |
| message is closed but not solved | underlying process is never opened | drill down into the linked process |
Links