Email notifications

Your notifications page decides which product emails iAdvize sends you. It holds two cards: Product updates, with a switch per email, and Job notifications, a read-only list of the emails that always go out.

Three ways to open it:

• Click your avatar at the bottom of the sidebar to open the user menu, then its header row to reach My account, then switch to the Notifications tab.
• The tab strip above Your settings and Account security.
• The address directly: /dashboard/account/notifications.

Everything on this page is personal: your own inbox, not your organization's. Emails go to the address on your account, shown under the page title. There's no way to send them somewhere else: the address isn't editable here, and it isn't editable on Your settings either.

Turn an email on or offCopy Anchor Link

Both switches are stored in one go, so you can't end up with one applied and the other not. If the save fails, both snap back to the state that was last stored and an error message says why.

Under each label the page repeats the send time and a Written in English badge: neither email is translated, whatever language your dashboard is in. The weekly row also links to the changelog, which opens in a new tab so you don't lose the page.

Both emails come from iAdvize Product <product@news.iadvize.ninja>, a different sender from the ones that carry sign-in and service messages. If you filter or allowlist mail, allowlist that address. Replies go to product@iadvize.com, not back to the sending address.

What's in the daily changelogCopy Anchor Link

One email per day, and it's the raw feed: every changelog entry dated the previous day, in the author's own words. Nothing is rewritten, shortened, or summarized.

The subject line names the email, the count, and the day: Daily changelog: 3 changes · Wed, Aug 19. It leads with the email's own name rather than "iAdvize", which your mail client already shows as the sender; with one sender for both product emails, that name is what tells them apart in a list and what a mail filter can match on. The day is there because a count on its own isn't unique: two days that each ship three changes would otherwise arrive under an identical subject, and mail clients thread by subject.

At the top of the email, the day is spelled out once ("Daily changelog · Wednesday, August 19, 2026") above the count as a headline. It isn't repeated on each entry, since every entry in the email shares it.

Each entry gets a row:

• its screenshot, or the same placeholder graphic the changelog shows for an entry that has none
• its type badge: Added, Changed, Fixed, Deprecated, Removed, or Security
• its title, linking to the full entry
• its description, exactly as the author wrote it
• a Read more link, so there's always something obvious to click

The email closes with a See the full changelog button. If a single day ever carries more than five entries, the email shows the first five and the button reads See all N changes instead. The subject still counts every one of them.

What's in the weekly product updateCopy Anchor Link

One email on Tuesday, covering the seven UTC days ending Monday. It's the same material as the daily, arranged by importance instead of by day.

The subject line leads with the email's own name, then the week's headline, and stops there: Weekly product update: Engagement widgets grew up this week. No date follows it: a written headline already differs from one week to the next, which is all it takes to keep two editions from threading together. On the weeks that arrive without a headline, the subject carries a count and the window's first day instead: the fallback described below. The top of the email names the window in full ("Weekly product update · August 13 → 19, 2026"), then that same headline, then usually a short opening paragraph.

Under the headline sits the week in numbers: 12 changes · 3 new · 4 improvements · 5 fixes. Those are counts of the week's own entries, one figure per type, with the types that had nothing left out rather than printed as zeros.

Then three sections:

• The change of the week: one entry, full width: a large image, its date and badge, its title, its description, and a Read more link.
• Also this week: up to four more entries as rows, each with its image, its date, its badge, its description, and a Read more link.
• The rest in brief: every remaining entry on one line, its badge and its title as a link. The titles here aren't underlined: stacked up, a dozen underlined lines read as a mistake rather than a list, so the badge beside each one carries the cue instead. Nothing is dropped for space, however busy the week.

Dates in this email carry the weekday (Wed, Aug 19) because its entries span several days and knowing which day is part of the point.

A section only appears when it has something in it, so a three-entry week is a lead change, two rows, and no third section, never a heading over an empty list. The email closes with a Read the full changelog button.

The digest is edited by a model, within hard limits. It writes the headline (which the subject line then carries, after the email's name) and the opening paragraph, picks which entry leads and which few get prominence (by usefulness, not by date), and may reword an entry's description so the whole email reads in one voice. Entry titles, type badges, dates, images, links, and the counted line under the headline are never generated.

What the model can't do is the part worth trusting. Four checks run over everything it wrote (the subject, the intro, and any reworded description), and failing one throws the whole output away, not just the offending line:

• No new figures. Each number, percentage, and price is compared as a whole value ("25%", "€49") against the figures in the week's own titles and descriptions. One that isn't there rejects the output, so a rounded or recombined figure fails too: the value has to appear in an entry as written.
• No change from outside the week. Naming a changelog entry that isn't in the window rejects the output, including as its choice of lead entry or of a prominent slot.
• Nothing dropped, nothing added. The final order has to be every selected entry, each exactly once. The model can promote or demote a change; it can't leave one out or bring one in.
• Reworded descriptions are bounded, not checked for meaning. A replacement has to belong to an entry in the week, not be empty, stay under a length cap, and pass the same figure check as the rest. Whether it still says what the author said is an instruction to the model, not something we verify mechanically, which is why leaving a description alone is its safe default, and why most descriptions are the author's own words.

If the output is rejected, if the model is unavailable, or if it judges the week too thin to summarize honestly, the digest still goes out: newest first, every description the author's own, the subject a plain count followed by the window's first day (Weekly product update: 4 changes · week of Aug 13), and no opening paragraph. That day is what keeps this version of the subject unique: a count repeats from one week to the next, where a written headline doesn't. The three sections and the counted line are unchanged: they don't depend on the model.

The daily changelog is never edited this way: no model touches it at all. If you want the unfiltered version, that's the switch to use.

Reading them on a phone, or in dark modeCopy Anchor Link

Both emails are one column of entries, and each entry adapts to the width it gets: on a wide screen the picture sits beside the text, on a narrow one it moves above the text and both take the full width. Nothing gets squeezed into a sliver of column.

A screenshot is scaled to fit its slot at its own proportions rather than stretched to fill it, so a tall capture and a wide one both arrive undistorted. If your mail client blocks images, each entry shows a short line naming it ("Screenshot: …"), not the long description the changelog page uses.

In dark mode, a client that asks for a dark version gets one; a client that inverts the email on its own gets a readable result too, because there's little tinted surface to invert. Either way a type is never carried by colour alone: Added, Fixed and the rest are written out next to their dot, so a mangled colour costs you nothing.

Unsubscribe straight from an emailCopy Anchor Link

Every product email carries three links in its footer: Manage notifications, which brings you back to this page, Unsubscribe, and RSS. Above them is the line saying which switch brought you the email. Below them, the sender in full (iAdvize SAS and its postal address in Nantes) and a reminder that every date in the email is a UTC calendar day. The header carries one more link, Read on the changelog, for when a mail client mangles the layout.

Unsubscribe opens the hosted preference page of our email provider (Resend), not an iAdvize page. Both emails are listed there separately, so you can drop the daily and keep the weekly (or the reverse) without signing in. The same page also offers Unsubscribe all, which stops both.

Whatever you do there is what this page shows next time you open it: unsubscribing from one email switches that row off here, and Unsubscribe all switches both off. Coming back and turning a switch on again undoes the block: you don't have to find the email again or contact support.

Emails that are always onCopy Anchor Link

The Job notifications card lists the emails you get because you launched something, each marked Always on:

There's no switch for either one today, which is why the card is read-only, and the switches above don't affect them. Turning both product emails off, or using Unsubscribe all, leaves these two arriving: they're sent as ordinary service messages, outside the subscription, and from a different address (notifications@email.iadvize.ninja).

When the switches don't appearCopy Anchor Link

There's no copy of your preferences on our side (the email service holds them), so if that read fails, the Product updates card shows a short message in place of the two switches. Nothing has changed, and nothing can be changed until the read works; try again in a few minutes. The Job notifications card still appears, because those emails don't depend on it.

An address the email service has never seen is not a failure: it reads as both switches off, which is exactly what it means: you've never subscribed to anything. Any other problem (the service unreachable, a request refused) shows the message instead. The two states look different on purpose: switches you can flip always reflect a real stored answer.

Subscribing from the changelogCopy Anchor Link

The public changelog carries the same offer under its heading. Signed in, it links straight to this page. Signed out, it links to sign-in first: there's no email box to type an address into, because a subscription is attached to an iAdvize account. If you don't have one and want the updates anyway, use the changelog's RSS feed.