Alerting, event routing and ownership

An alert without an owner is worse than no alert: it trains people to ignore the channel. In SAP Cloud ALM, alerts and notifications come from Intelligent Event Processing (IEP), the component that routes events between producers and consumers. The design work is deciding, for each event, who must act, how they are told, and what happens if they do not.

How events flow

Some details matter for design. SAP distinguishes event situations, which open, may update and later close, from stateless events, which open and close at once, such as a specific application log message; stateless events cannot be updated or auto-closed later. Event processing rules are normally created and managed in the source monitoring app and shown read-only in IEP; SAP describes manual rules in IEP as for exceptional cases. Not every action is available for every use case (Business Service Management, for example, does not create alerts), and IEP's overview shows triggered events and failed actions with error messages, which is where to look when an expected email never arrived.

Ownership by design

Under RISE, ownership also crosses company lines. When CMP's health turns critical, SAP ECS acts on the platform, but Contoso still decides what it means for the business, informs users and confirms the resolution, because the R&R makes sign-off of incident resolution a customer task. Route such events to Sam for awareness rather than duplicating SAP's technical response.

Severity and timing need the same care as ownership. A failed EDI invoice at 23:00 can wait for the integration specialist's morning if the customer collects invoices at 08:00; a failed payment run on the day suppliers must be paid cannot. Write the business deadline into each alert definition, so the escalation time follows the business, not a generic priority table. Wave 2 adds a twist: Monterrey works in a different time zone and its own month-end calendar, so alerts for company code 1910 need owners who are awake when they fire.