A banner is the middle setting between saying nothing and stopping everything. It's visible while people carry on working, which makes it right for maintenance windows, expiring trials and anything true for a while and then not.
A floating banner sits over your interface; an inline one takes its place in the page and pushes the content down.
Inline is the safer choice in a dense application. A floating banner is more noticeable and can end up covering something — a toolbar, a control at the top of a table — which is fine for a day and irritating for a week.
You choose whether to show a dismiss button. Leave it on for anything informational — a banner someone can't get rid of is a banner they resent.
The case for leaving it off is narrow: something they genuinely need to keep seeing, like an expired payment method blocking their account. And even then, dismissing it once and having it return the next day is usually better than never letting it go.
A banner can carry an action — opening a URL, optionally in a new tab, or triggering something in your own product through a named custom action.
The custom action is the better one where it applies: sending someone to the right screen inside your app beats sending them to a page about the screen.
You can also show the sender, which puts a face on it, and set the text alignment. For heavier customisation there's a custom CSS field.
A banner is read in passing, so it has to work in one line. Say what's happening and what to do: “Scheduled maintenance Sunday 02:00–06:00 UTC” works; two sentences of context don't get read at all.
Limit it to the pages where it's relevant. A notice about export problems belongs on the export screen, not on every page — and a banner shown everywhere is the fastest way to make people stop seeing banners.
