> ## Documentation Index
> Fetch the complete documentation index at: https://assembly.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Configuring notifications

> Adjust the notifications an app you built sends to your team, and how they're delivered.

When the app builder builds an app that needs to notify someone, it sets up the notifications as part of the build. You don't have to configure anything to get them working. This page is where you adjust them afterward — rename them, change how they're delivered, or add one the build didn't include.

## Where to find them

Two routes to the same place:

* **From the app:** click the app name at the top, then **Manage app**.
* **From the App Library:** click the menu button **(...)** next to the app, then **Edit app**.

On the app's edit page, open **Advanced** and find **Configure notifications**.

## What a notification setting is

Each row is one kind of notification the app sends — an event worth telling someone about. The **Product** and **Email** labels on each row show where that notification can be delivered.

These rows become the app's section on every internal user's notification settings page, under **Settings** > **Notifications**. What you set here is the starting point; each teammate can then turn product or email delivery on or off for themselves.

Use **Add notification setting** to create a row, the pencil to edit one, and the trash icon to remove one.

<Warning>
  Rename a notification freely — renaming keeps everyone's delivery preferences intact. Deleting a row and adding a replacement looks the same on screen but is treated as a different notification, so every teammate's preference for it resets to the default.
</Warning>

## These settings are for your team

Everything in this panel applies to internal users. Clients have no notification settings page, so nothing here changes what your clients receive.

## Changing what clients receive

Client notifications live in the app itself, so changing them is a change to the app. Ask for it in the build chat — "notify the client when their intake is approved," or "stop emailing clients when a document is uploaded." See [Iterating on apps](/docs/building-new-apps/iterating-on-apps).

Your workspace-level client email settings still apply on top of whatever the app sends. See [Client notifications](/docs/core-concepts/client-notifications).

## Action label

The **Action label** fields sit in the same panel but do something different, and for a different audience.

They give the app a row in the **Actions** section of a client's [Client Home](/docs/built-in-apps/home), written as *\[verb] \[count] \[noun]* — "Review 3 documents", "Complete 1 form". Fill in the verb, the singular noun, and the plural noun; all three are needed, and the row is skipped entirely if any is blank.

The count is that client's own unread notifications from the app, so the row only appears when they have something waiting. Two things follow from that:

* The app has to notify **clients**, not just your team. Notifications sent to internal users never produce a row.
* Word it as the work the client does — complete, sign, approve, upload. If your team is the one doing the reviewing, no row will ever appear, even though the fields look correctly filled in.

## Edits and rebuilds

Changes here take effect immediately. If you later have the app builder rebuild the app, the notification setup in the app's code takes precedence — so for a change you want to keep, ask the builder for it rather than editing this page.