Alert Your Team in Slack When EDI Orders Fail (Boomi + NetSuite)

If your business exchanges EDI documents with retail trading partners, you know that a failed document is rarely a quiet failure. A purchase order (850) that never made it into NetSuite means a late shipment. An invoice (810) that is rejected means delayed payment. And the first you hear about it might be an angry email from the partner.

Slack can turn that around. Instead of finding out the next morning, the right people see the failure within a minute, along with the details needed to fix it.

This page shows two ways to do it: from Boomi (or any middleware), and from NetSuite scripts that process EDI-related records.

The scenario

Documents flow like this:

Trading partner → (EDI network) → Boomi → NetSuite

Things that commonly go wrong:

• An 850 arrives with an item number NetSuite does not recognise.
• A ship-to address cannot be matched to a customer.
• A NetSuite record fails validation (missing required field, closed period, inactive item).
• A connection times out or a token expires.
• An outbound 856 or 810 is rejected by the partner.

For every one of those, we want a Slack message that says what failed, for which document, and why, with a link where possible.

What a good EDI alert says

:rotating_light: EDI error: 850 purchase order failed to import
Partner:   Example Retailer
PO number: 4500123456
Reason:    Item "CAB-B36-WH" not found in NetSuite
Process:   850 Inbound to NetSuite Sales Order
Time:      2026-09-23 06:41

Five facts, no scrolling. Whoever picks it up knows whether it is a data issue (fix the item mapping), a connection issue (retry) or a partner issue (contact them).

Part A: Set up a dedicated channel and webhook

1. In Slack, create a channel called #edi-alerts (or #integration-alerts if you want one channel for everything).
2. Add the right people: EDI analyst, integration developer, customer service lead.
3. In your Slack app, add a new incoming webhook for this channel (see Step 1).
4. Store the webhook URL somewhere safe. In Boomi, use a process property or an environment extension so it is not baked into the process and can differ between test and production.

Part B: Alert from Boomi

You do not need a special Slack connector. Boomi’s standard HTTP Client connector is enough.

Step by step

1. Find where errors already happen. Open your EDI process and locate the Try/Catch shape around the NetSuite step. If there is none, add one. The Catch branch is where the alert lives.

2. Collect the facts you want to show. On the Catch branch, add a Set Properties shape, or reuse properties you already have. Capture the partner name, the PO number, the process name and the error message. Boomi provides the error message from the Try/Catch through a built-in reference.

3. Build the JSON with a Message shape. Add a Message shape containing something like this:

{
  "text": ":rotating_light: EDI error: {1}",
  "blocks": [
    { "type": "header", "text": { "type": "plain_text", "text": "EDI error" } },
    { "type": "section", "fields": [
      { "type": "mrkdwn", "text": "*Partner*\n{2}" },
      { "type": "mrkdwn", "text": "*Document*\n{3}" },
      { "type": "mrkdwn", "text": "*Process*\n{4}" },
      { "type": "mrkdwn", "text": "*Reason*\n{5}" }
    ] }
  ]
}

Then map {1} to {5} to your properties in the Message shape’s variable list.

4. Send it with an HTTP Client connector. Add a Connector shape, choose HTTP Client, and configure the operation as a POST with content type application/json. Point the connection’s URL at your webhook URL (from the process property).

5. Do not let the alert hide the error. After the HTTP call, end the branch the way your process normally handles failures. For example, use a Stop with an exception, or a Return Documents shape to keep a record of the failure. The Slack message should be in addition to your usual error handling, never instead of it.

Watch the quotes

Error messages often contain quotation marks, line breaks or backslashes. Dropped straight into JSON, they can produce an invalid message and Slack will answer invalid_payload. Clean the error text before it goes into the Message shape. One way is a small Data Process shape with a script that escapes quotes and new lines. Another is to trim the message to its first line and about 300 characters.

Test it

1. Run the process in a test environment with a document you know will fail (for example, an item number that does not exist).
2. Check that a message shows up in your test channel.
3. Check the process still ends in the state you expect (failed, with the document retained).

Part C: Alert from NetSuite itself

Sometimes the error is not in Boomi but inside NetSuite: a script that turns an inbound record into an order, or a RESTlet that Boomi calls. Use the same pattern from Step 2 in the catch block:

} catch (e) {
  log.error('EDI order creation failed', e.name + ': ' + e.message);

  slack.postToWebhook(ediWebhookUrl, slack.buildAlert({
    title: 'EDI error: order could not be created',
    summary: 'EDI order creation failed for PO ' + poNumber,
    facts: [
      ['Partner',   partnerName],
      ['PO number', poNumber],
      ['Reason',    (e.message || '').substring(0, 300)],
      ['Script',    runtime.getCurrentScript().id]
    ]
  }));

  throw e;   // Keep the original failure behaviour, so Boomi knows the call failed.
}

The reusable slack_lib.js helper is described on the Block Kit page.

Two tips:

• Rethrow the error (or return your usual error response) so the caller still knows something went wrong. The Slack message is for humans; the error response is for the system.
• Keep the Slack call inside its own try/catch if you are worried it might fail during an already-failing run.

Part D: Reduce the noise

EDI can be chatty. A partner sending 500 orders with the same bad item code could produce 500 identical alerts and bury everything else. A few ways to stay sane:

• Group by cause. Send one message per batch: “37 orders failed: item CAB-B36-WH not found.”
• Alert on the first failure and then a summary. The first gets a full message and the rest are counted.
• Use a threshold. For minor issues, alert only if failures exceed a set number in an hour.
• Use threads. Post follow-ups in a reply to the original message so the channel stays clean.
• Add a daily summary. A morning digest (see the digest page) listing yesterday’s failed and successful documents, per partner, is often more valuable than any single alert.

Part E: Handling the alert in Slack

Agree on a simple habit so nothing gets dropped:

1. Whoever picks up the alert replies with an eyes emoji or “On it”.
2. When fixed, they reply “Fixed, reprocessed” (and add a check mark reaction).
3. If it needs the partner, they reply with who they contacted.

That is a lightweight incident log for free, and it is searchable later.

Checklist

• ☐ Separate webhook per environment (test and production)
• ☐ Webhook URL stored in a process property or environment extension
• ☐ Error text cleaned before going into JSON
• ☐ Slack alert sits alongside existing error handling, not in place of it
• ☐ A plan for repeated errors (grouping, thresholds or threads)
• ☐ Clear owner for the channel

What is next

Learn how to keep all these channels useful in Best Practices: Keep Slack Useful, Not Noisy.