Best Practices: Keep Your NetSuite and Slack Integration Useful, Not Noisy

Getting a message into Slack is the easy part. Keeping the integration helpful a year later, when there are twenty alerts, three developers and a few hundred people in the workspace, takes a little planning. These are the habits that make the difference.

1. Design your channels first

Channels are the user interface of your integration. A few simple rules:

• One purpose per channel. #po-approvals, #edi-alerts and #finance-daily beat one giant #netsuite channel.
• Use a clear naming pattern, such as ns- or alerts- at the front, so people can find and mute them easily.
• Make each channel’s owner obvious. Put it in the channel description: “Owner: Jane. Purpose: EDI failures. Runbook: link.”
• Invite only the people who need it. Sensitive channels should be private.
• Have a separate test channel for the sandbox and never mix test and real alerts.

2. Send fewer, better messages

The number one reason integrations fail is not technical, it is that people mute the channel.

• Every alert should have an action. If nobody needs to do anything, it belongs in a digest.
• Prefer exceptions to events. Alert on “order stuck for 2 hours”, not “order created”.
• Group repeats. One message saying “37 items failed” beats 37 messages.
• Set thresholds and review them. If a channel gets more than a handful of alerts a day, ask what can be cut.
• Ask the audience. After a month, ask: “Is this useful? What would you change?”

3. Write messages people can read in five seconds

• Put the what happened in the first line.
• Show three to five key facts, not twenty.
• Always include a link back to the record.
• Keep formatting consistent so people learn to scan.
• Add a plain text fallback for notifications (see the Block Kit page).

4. Respect Slack’s limits

Slack protects itself from floods. Rates are documented in Slack’s API docs and can change, but as a working rule:

• Aim for about one message per second per channel at most.
• If Slack answers with HTTP 429, it is saying “slow down”, and it includes a Retry-After header telling you how many seconds to wait.
• Do not loop over hundreds of records and fire a message for each. Batch them into a single summary.

5. Respect NetSuite’s limits

• Each HTTP call uses governance units. A User Event script has a fixed allowance per run, so one Slack call per save is fine but dozens are not.
• Keep calls out of the user’s way. A slow Slack response should never make someone wait to save a record. Use afterSubmit, not beforeSubmit, and never call Slack from a client script.
• Move heavy work to a queue. If you need to send many messages, write them to a custom record and have a Scheduled or Map/Reduce script send them in batches.
• Set timeouts and handle failures. Wrap every Slack call in try and catch, log the failure, and carry on.

6. Plan for failure

Slack will occasionally be slow or unavailable, tokens will expire, and someone will delete a channel.

• Always catch errors. The business transaction must never fail because a notification failed.
• Log clearly. A good log line names the script, the record and the Slack error text.
• Decide what “lost alert” means. For low-stakes messages, a lost alert is fine. For critical ones (a failed payment file, say), also send an email or write a task record as a backup.
• Know your channels of last resort. If the Slack app is broken, who finds out and how?

7. Be careful with people’s data

• Prefer links to data. Slack is not a system of record.
• Never include payment details, bank details, personal addresses, tax numbers or confidential pricing.
• Know how long Slack keeps messages in your workspace, and who can export them.
• Give your Slack app only the permissions it needs.
• Review who is in each channel every few months.

8. Manage change like any other NetSuite customisation

• Develop in a sandbox, promote with SuiteCloud tools or a bundle, and keep the scripts in version control.
• Use one library file for Slack helpers rather than copy-pasting code into each script.
• Keep a short inventory listing every alert: name, script, channel, owner, and what it is for. A spreadsheet is fine.
• Document how to rotate tokens and who is responsible.
• Sandbox refreshes: after a refresh, check that test deployments do not point at production channels.

9. Make it easy to turn things off

• Put an on/off checkbox parameter on each script deployment so an admin can silence an alert quickly.
• Consider a company-wide “kill switch” parameter for all Slack notifications in case of a flood.
• Use the deployment Status field to pause an alert without deleting anything.

10. Measure whether it helps

After a month or two, look for evidence:

A one-page launch checklist

• ☐ Sandbox tested end to end
• ☐ Separate test and production webhooks and channels
• ☐ Secrets stored in the right place
• ☐ All Slack calls wrapped in try and catch
• ☐ On/off switch on every deployment
• ☐ Channel owner named and description written
• ☐ Alert inventory updated
• ☐ Users told what to expect and what to do

What is next

Something not working? Head to Troubleshooting and FAQ.