Rivya Notifications Center Guide

Use this notifications center guide when you need to understand billing events, credit changes, generation status, unread items, and where to follow up after an event.

Rivya’s notifications center is not there to make the product feel busy.

It exists because some events still matter after the moment when they first happened.

The Real Question Notifications Answer

Notifications are most useful when you are not asking:

They are asking:

That is why notifications are different from both history and settings.

Notifications Are for Operational Events, Not General Activity

The current live notification stream is organized around three practical kinds:

• billing
• credits
• generation

There is also an account kind in the broader data model, but the active user-facing stream is intentionally centered on the three kinds above.

That is a product choice, not a missing feature. The system is trying to preserve useful signal, not every possible event.

The Events That Actually Matter Here

Right now, the most important durable notification events include:

• subscription started
• subscription renewed
• payment failed
• credit package added
• generation succeeded
• generation failed
• insufficient credits

Those are not just status decorations. Each one can change whether the user should continue work, top up, reopen something, or investigate a failure.

Why a Notification Exists Even When Another Page Also Shows the Result

That is exactly what makes the center useful.

A generation can already be visible in history. A billing change can already show up in billing or credits pages.

Notifications still matter because they answer the cross-cutting question:

That is why the same event can appear:

• in the related workspace or settings page
• and in notifications as a durable operational record

Dashboard Preview vs Full Notifications Page

The dashboard preview is the short version.

It is there to answer:

• do I have unread items?
• is there anything urgent?
• should I open the full center?

The full /notifications page is where you get the longer operational view.

It currently gives you:

• a feed of recent notifications
• counts by kind
• unread state
• a mark-all-read action
• links back to the most relevant product page

That last part matters more than it sounds. A useful notification should take you somewhere actionable.

Notifications vs History

Use History when the main question is:

Use notifications when the main question is:

If a generation failed, notifications may be the first place you notice the problem. History is where you reopen the broader work record around that task.

Notifications vs Settings

This distinction is worth keeping very clear:

• settings manage what you control
• notifications preserve what already happened

For example:

• newsletter preference belongs in settings
• a failed payment belongs in notifications

Treating those as the same thing usually makes the product harder to reason about.

When the Notifications Center Is Most Useful

The center becomes most valuable in moments like these:

• you were away and want to know whether anything important changed
• a run seemed fine, but something later failed
• checkout completed and you want to confirm what the account actually recorded
• credits ran low and you need to decide whether to top up or stop

These are the moments when a toast is too temporary and a full history page is too indirect.

A Practical Notification Habit

For most users, a good pattern is:

1. use dashboard to spot whether something needs attention
2. open the full notifications page when the short preview is not enough
3. follow the related link back into the right workspace or settings page

That keeps notifications acting like an operational workspace instead of a passive inbox.

Read Next

• History
• Task Lifecycle
• Image Workflows in Rivya
• Video Workflows in Rivya
• Audio Workflows in Rivya
• Dashboard in Rivya
• Troubleshooting in Rivya
• Why Rivya Has a Notifications Center

Notification Review Checklist

When you need to understand an event instead of only the final output, check:

• Check whether the notification is about billing, credits, generation, or account state.
• Connect generation alerts back to the task record and history item.
• Connect payment and credit alerts back to billing or credits settings.
• Treat notifications as status context, not as a replacement for invoices, task details, or wallet history.
• Use unread state for triage, not as proof that an event is unresolved.

Recheck When Status And History Disagree

Recheck if a notification says one thing while history, wallet, or billing state says another. The latest settled account state should decide the next action.