Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 5

Alerting and ownership

10 min

Listen to this lesson

0:00 / 6:22

A monitor nobody watches is a log. Alerting turns a failure into a task for a named person, fast enough that the business does not notice. The hard part is not the technology. It is deciding who owns which error, how urgent it is, and how to avoid drowning owners in alerts they cannot act on.

Ownership follows the fix

Route each error to the person who can fix its cause. A message that failed because a customer is blocked for sales is a business error: Maria's order-to-cash team fixes the master data. A message that failed because a certificate expired is a technical error: Theo's integration team fixes it. Sending both to one shared inbox guarantees that each team waits for the other.

  1. Can a key user fix it by correcting business data?Yes → route to the process team (for example, Maria for order-to-cash), ideally where they can correct and restart · No → next question
  2. Is it connectivity, credentials, certificates or capacity?Yes → route to integration or Basis on-call (Theo or Sam) · No → next question
  3. Is it a mapping or code defect?Yes → route to the integration developer or Kenji's ABAP team as a defect · No → next question
  4. Unknown?Route to the integration on-call for triage with the full error text and business key
Routing an interface error to the owner who can fix its cause.
The Sign-Off Table · thesignofftable.com/academy/sap-int-205

Alert rules in SAP Cloud ALM

In SAP Cloud ALM's Integration and Exception Monitoring, you turn on data collection per category for each registered system or service, then define events with filters, for example messages in error status for a given component or scenario. Each event can trigger actions: create an alert in the alert inbox, send an email to verified recipients, send a chat notification, create a ticket, or start an operation flow. In the alert, a user can assign a processor, comment and confirm. SAP's guidance is to enable collection first, confirm data arrives, then add filters and finally events and actions.

An alert in SAP Cloud ALM is a task: someone takes it as processor, works it with comments, and confirms it when the cause is fixed.
The Sign-Off Table · thesignofftable.com/academy/sap-int-205
  1. RegisterCMP and the production Integration Suite tenant registered as managed systems and services.
  2. CollectData collection switched on per category; data checked on the home page.
  3. GroupBusiness service Procure-to-Pay EDI groups the S/4HANA, Cloud Connector and flow components.
  4. DetectEvent: error status on the Lakeside flow, or more than 20 orders waiting in the JMS queue.
  5. ActCreate alert, email the P2P integration on-call, open a ticket for anything open over two hours.
Setting up alerting for Contoso's supplier order interface in SAP Cloud ALM.
The Sign-Off Table · thesignofftable.com/academy/sap-int-205

Severity and noise

Not every failed message is urgent. A failed order to a supplier on a Friday afternoon may stop production on Monday; a failed product description update to the web shop can wait a day. Agree severity per interface with the process owner, based on business impact and time to harm, and write it in the interface's run book. Then alert on what needs action, not on everything: a retry that succeeds on the second attempt does not need a human.

Daily reviewLow impact, slow harm: product text updates; batch report next morning
Business-hours alertLow impact, fast harm: price list to the web shop; alert in working hours
Same-day ticketHigh impact, slow harm: month-end statistics feed; ticket with a deadline
Immediate on-callHigh impact, fast harm: supplier orders, bank payments, carrier labels; page on-call at any hour
Agreeing alert severity per interface with the process owner.
The Sign-Off Table · thesignofftable.com/academy/sap-int-205
Every noisy rule ends in one of three fixes, so that the alerts left are the ones owners act on.
The Sign-Off Table · thesignofftable.com/academy/sap-int-205

What would you do?

During Contoso's final integration test cycle, every failed message in every interface sends an email to one shared mailbox. Luis, the cutover manager, asks whether this is ready for hypercare. What should Theo propose?

Key points
  • Route each error to the owner who can fix its cause: business, technical or development.
  • In SAP Cloud ALM, collect data first, then define events and actions such as alerts, emails and tickets.
  • Agree severity per interface by business impact and time to harm.
  • Tune out noise; an alert nobody acts on hides the ones that matter.

Check your understanding · not graded

Lesson check

  1. 1. A message fails because the customer is blocked for sales. Who should get the alert?

  2. 2. In SAP Cloud ALM, what defines the condition that triggers an alert action?

  3. 3. Which two factors should set an interface's alert severity?

  4. 4. A rule fires 50 times a week and nobody ever acts. What should happen?