Map and Route Alerts

Before you start

• Open a source that already has a real sample attached.
• Decide whether the source should always go to one system or function, or should look that up from the payload.

Do this

1. Open the source and go to Mapping.
2. Map the fields responders need most: summary, body, severity, status, dedupe key, external id, environment, and source URL.
3. Map labels if you want searchable tags carried across from the source.
4. Choose the binding mode in Routing:
   • Match from payload when the payload contains system or function keys.
   • Always route to one system when the source is dedicated to one service.
   • Always route to one function when the source always represents one flow.
   • Leave unbound when you want to ingest first and classify later.
5. If you use payload lookup, set the system and function key paths and any fallback paths you need.
6. Review severity and status mapping overrides if the sender uses non-standard values.
7. Save the source and send a test event.

Check it worked

• The alert summary is readable without opening raw payload data.
• The alert lands on the correct system or function.
• Repeated alerts dedupe the way you expect.
• The environment and labels match the incoming event.

If it does not work

• If the alert lands in the wrong place, fix binding mode and key paths before you change ownership or paging.
• If duplicates keep opening, check the dedupe key and external id mapping.
• If severities look wrong, add explicit severity map entries instead of relying on guesswork.

Next

• Use diagnostics and replay
• Review Beacon suggestions