Prevent Duplicate Slack Notifications from Google Forms

A Google Forms to Slack notification script usually starts simple:

Google Form
-> Google Sheet
-> Apps Script trigger
-> Slack Incoming Webhook

That is a good starting point.

But the first time the same response appears in Slack twice, the problem usually gets misdiagnosed.

People check the Slack message template.

They rewrite the payload.

They add another condition.

But duplicate Slack messages are usually not a formatting problem.

They are an idempotency problem.

If your script creates a side effect, it needs to know whether that side effect already happened.

The Practical Diagnosis

When a Google Forms response posts to Slack twice, check these three things first:

Symptom	Likely cause	What to inspect
The same function runs twice	Duplicate Apps Script triggers	The trigger list
Two executions race each other	No lock around shared state	Execution logs and timestamps
Retrying sends another message	No sent-state record	`notification_key` / `slack_notified_at`

Do this before you change the Slack payload.

The payload is often fine.

The workflow state is the fragile part.

I have been building FORMLOVA, a form operations product where notifications, response status, exclusions, reminders, and analytics are treated as post-submit operations instead of hidden spreadsheet side effects.

One lesson keeps repeating:

A notification is a side effect. Side effects need state.

1. Check for Duplicate Triggers

Apps Script installable triggers are easy to create.

That is useful.

It is also how teams accidentally create duplicate notifications.

A setup function like this can create another trigger every time it is run:

function createTrigger() {
  const spreadsheet = SpreadsheetApp.openById("YOUR_SPREADSHEET_ID");

  ScriptApp.newTrigger("onFormSubmit")
    .forSpreadsheet(spreadsheet)
    .onFormSubmit()
    .create();
}

If you run this during setup, then again during testing, then again after a teammate changes something, you may now have multiple triggers calling the same handler.

Start in the Apps Script trigger UI:

Apps Script
-> Triggers
-> check whether the same handler appears more than once

Also remember that installable triggers run under the account that created them. Google documents that triggers can be created per account, and one account may not see triggers installed by another account even though they can still run.

So if the duplicate notification appeared after a handoff, ask:

Did another account create the same trigger?
Did another Apps Script project post to the same Slack channel?
Did a test project keep running?

The first fix is often deleting duplicate triggers, not editing the Slack message.

2. Make Trigger Setup Idempotent Too

Do not let setup code create a new trigger every time it runs.

At minimum, check whether the handler is already registered in the current project.

const HANDLER_NAME = "onFormSubmit";

function createTriggerIfNeeded() {
  const triggers = ScriptApp.getProjectTriggers();
  const exists = triggers.some((trigger) => (
    trigger.getHandlerFunction() === HANDLER_NAME
  ));

  if (exists) {
    console.log(`${HANDLER_NAME} trigger already exists`);
    return;
  }

  const spreadsheet = SpreadsheetApp.openById("YOUR_SPREADSHEET_ID");

  ScriptApp.newTrigger(HANDLER_NAME)
    .forSpreadsheet(spreadsheet)
    .onFormSubmit()
    .create();
}

This only protects the current script project.

It does not prove that no other account or project created a similar trigger.

But it prevents the most common self-inflicted version of the problem.

3. Build a Notification Key

Next, give each notification attempt a stable key.

For a quick Sheets-side implementation, you might use the response row and submitted timestamp:

function buildNotificationKey(e) {
  const rowNumber = e.range.getRow();
  const timestamp = (e.namedValues["Timestamp"] || [""])[0];

  return `google_form:${rowNumber}:${timestamp}`;
}

That is not perfect.

The timestamp column name can vary by form language and sheet configuration. Row numbers can also become awkward if humans copy or move data later.

For a stronger design, use a form response ID or store a dedicated response record with fields like:

response_id
submitted_at
notification_key
slack_notified_at
slack_status
owner
status

The key idea is simple:

Before posting, identify which notification this is.
After posting, record that it was sent.

4. Store "Already Sent" State

For a small script, PropertiesService.getScriptProperties() can store simple key-value state.

function onFormSubmit(e) {
  const key = buildNotificationKey(e);
  const properties = PropertiesService.getScriptProperties();

  if (properties.getProperty(key)) {
    console.log(`already notified: ${key}`);
    return;
  }

  postToSlack(buildSlackMessage(e));

  properties.setProperty(key, new Date().toISOString());
}

Now a retry can see that the response was already posted.

This is a minimal pattern, not a complete operations system.

For a real team, I would rather put slack_notified_at and slack_status somewhere visible, such as a response records sheet or a proper response-management surface.

Hidden script properties are useful for a small guard.

Visible response state is better for team operations.

5. Lock the Check/Post/Write Section

There is still a race condition.

Two executions could both check the state before either one writes it.

So the critical section should be:

check whether this notification was sent
post to Slack
write slack_notified_at

Guard that section with LockService.

function onFormSubmit(e) {
  const lock = LockService.getScriptLock();

  if (!lock.tryLock(10 * 1000)) {
    console.log("could not acquire lock");
    return;
  }

  try {
    notifyOnce(e);
  } finally {
    lock.releaseLock();
  }
}

function notifyOnce(e) {
  const key = buildNotificationKey(e);
  const properties = PropertiesService.getScriptProperties();

  if (properties.getProperty(key)) {
    console.log(`already notified: ${key}`);
    return;
  }

  postToSlack(buildSlackMessage(e));

  properties.setProperty(key, new Date().toISOString());
}

Locking only the Slack HTTP request is not enough.

The lock needs to cover the read, the side effect, and the write.

6. Record Sent State After Slack Succeeds

Do not mark the notification as sent before Slack accepts the request.

const SLACK_WEBHOOK_URL = getSlackWebhookUrl();

function postToSlack(text) {
  const response = UrlFetchApp.fetch(SLACK_WEBHOOK_URL, {
    method: "post",
    contentType: "application/json",
    payload: JSON.stringify({ text }),
    muteHttpExceptions: true,
  });

  const status = response.getResponseCode();

  if (status < 200 || status >= 300) {
    throw new Error(`Slack notification failed: ${status}`);
  }
}

The order matters:

post to Slack
if Slack succeeded, write slack_notified_at
if Slack failed, keep it retryable

This does not solve every delivery ambiguity in the universe.

But it is much better than blindly reposting every time a script is retried.

7. Do Not Commit the Webhook URL

Slack Incoming Webhook URLs contain secrets. Slack explicitly tells developers not to share them online or commit them to public repositories.

In Apps Script, read the webhook URL from script properties or another secret store.

function getSlackWebhookUrl() {
  const url = PropertiesService
    .getScriptProperties()
    .getProperty("SLACK_WEBHOOK_URL");

  if (!url) {
    throw new Error("SLACK_WEBHOOK_URL is not configured");
  }

  return url;
}

This is not only a security issue.

It also makes the workflow easier to move between test and production without changing source code.

The Checklist

If your Google Forms workflow posts duplicate Slack messages, check this:

[ ] Is the same Apps Script handler registered more than once?
[ ] Did another account create a trigger you cannot see?
[ ] Is a test script still connected to the same Slack channel?
[ ] Does each notification have a stable notification_key?
[ ] Does the script check sent state before posting?
[ ] Does the script write slack_notified_at only after Slack succeeds?
[ ] Is the check/post/write section protected by LockService?
[ ] Is the Slack webhook URL stored outside public source?

Duplicate notifications are annoying, but they are also useful.

They reveal that the workflow has hidden state.

Once a script has hidden state, the next bugs are usually about ownership, retries, status, exclusions, and reporting.

That is the point where the workflow is no longer "just a Slack notification."

It has become response operations.

Where I Draw the Line

If all you need is awareness, a simple Slack notification may be enough.

If you need to know whether a response is new, in progress, resolved, excluded, retried, or assigned to someone, the notification should become only one event in a response record.

That is the model I use in FORMLOVA:

response saved
-> notification attempted
-> notification result recorded
-> owner/status updated
-> unresolved responses stay visible

The goal is not to replace every Google Forms workflow.

The goal is to stop pretending that "message posted" means "work handled."

References

Related FORMLOVA Guides

Try FORMLOVA | MCP setup guide

推荐订阅源

DEV Community