Two audiences, two channels
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.Internal user notifications
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.Client notifications
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