---
title: How to notify someone from a workflow
url: https://tideswell.xyz/docs/workflows/notify-someone
description: Tell one person or a whole department, with a message carrying values from the record that set it off.
---

> Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further.

# How to notify someone from a workflow



**Notify someone** sends a notification to one person, or to everyone in a department. It is the
step to use when somebody needs to know rather than needing to do.

## When is a notification the right step? [#when-is-a-notification-the-right-step]

When the information is the whole point and no work follows from it.

"The fabric trial was approved" is a notification to production. "Book the factory slot" is a
task with an owner and a date, per <Ref to="workflows/create-tasks-and-records" />.

The test: if nobody would tick it off, it is a notification.

## How do you set one up? [#how-do-you-set-one-up]

Add the step, then choose the recipient, either one person or a department, and write the
message.

Put values from the triggering record in the message, so it says which thing happened. See
<Ref to="workflows/use-values-from-the-record" />.

Publishing refuses a Notify step with no message or no recipient.

## How does it reach people? [#how-does-it-reach-people]

As a push notification to a phone or browser.

That means it is subject to each person's own notification settings. A notification landing
inside somebody's quiet hours is **dropped rather than held** until morning, and the step's own
panel says so.

Design around that. For something that must be seen regardless of the hour, create a task
instead: a task waits in a list, and a push does not.

See <Ref to="notifications" /> for the personal side.

## Why did a Notify step fail? [#why-did-a-notify-step-fail]

Because the department you chose has nobody active in it, and the run says exactly that.

That is worth checking when you build a workflow against a small team, and worth rechecking when
somebody leaves.

## What does the run tell you? [#what-does-the-run-tell-you]

A line like "Told 3 people, 2 devices buzzed".

The gap between those numbers is normal rather than a fault. Somebody had notifications off, or
was inside their quiet hours, and the run records "no push went out" as an ordinary outcome.

The message is shown **as configured**, with placeholders unfilled. The notification that went
out had the real values; the run records the setup rather than the filled text. See
<Ref to="workflows/publish-and-read-a-run" />.

## Who should you notify? [#who-should-you-notify]

A department rather than a person, in most cases.

Naming one person makes the workflow break when they are on holiday or leave. Naming a
department means the right people get it as the team changes, and departments are managed in one
place. See <Ref to="workspace-admin/departments" />.

Name a person when the thing genuinely belongs to a role only they hold.

## Can it send an email? [#can-it-send-an-email]

The built-in automations offer **Also email**, per
<Ref to="automations/choose-who-gets-alerted" />. A workflow's Notify step sends a push.

When something has to arrive by email, an automation is the better tool. When it has to be seen
in Tideswell, create a task, which appears in a list and stays there.