> ## Documentation Index
> Fetch the complete documentation index at: https://studio.assembly.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Notifications
Notifications are how an app reaches someone outside the app itself. When an invoice is approved, a check-in is submitted, or a deadline is missed, the app can ping the right person through the right channel.
## Two audiences, two channels
| | Internal users | Clients |
| ---------- | ----------------------------- | ---------------------------- |
| In-product | Dashboard notification center | Sidebar badge on the app |
| Email | From your workspace's sender | From your workspace's sender |
Apps decide which audiences they notify and which channels they use. Most apps use both audiences when relevant, and pick channels based on urgency — in-product for routine, email for things you need someone to see even if they aren't signed in.
## How internal notifications work
Internal notifications land in the Dashboard's notification center, accessible from the top of the screen. They auto-clear when the user views them.
If the app also sends email, the same notification arrives in the internal user's inbox. Internal users can configure their own preferences for which apps email them.
Configuration details in the Assembly Studio guide
## How client notifications work
Client in-product notifications show up as a badge counter next to the app in the Portal sidebar. The badge stays until the app clears it — typically when the client opens the relevant screen.
This means an app that creates in-product notifications for clients has a job: clear them on the client's behalf when the client has done the thing the notification was about. The app builder handles this by default for the patterns it knows. If you're building something novel and the badge sticks, mention it in the build chat.
Email notifications to clients come from your workspace's sender. If you've connected a custom email domain, they come from your domain.
Configuration details in the Assembly Studio guide
## How the app builder decides what to send
During the planning step, the product agent proposes a notification setup: the trigger events, the audience, and the channel for each. You'll see this in the plan before the build starts.
Typical notification proposals look like:
* When a client submits a form → notify the assigned internal user → in-product
* When a deadline passes without action → notify both client and internal user → email
* When an internal user approves a request → notify the client → both
You can edit these in the plan, or change them later by saying so in the build chat.
Be deliberate about email. Internal users will tolerate a lot of in-product noise but very little email noise. Clients will tolerate even less. The apps that drive adoption are the ones that email sparingly and use in-product for the rest.