saleor-dashboard-feedback

Use inline field or section errors when the merchant must fix something on the page, and toasts only to acknowledge terminal, non-blocking outcomes of an action they just took. Serious failures pair a short toast with a persistent banner or inline surface.

Map GraphQL errors to form fields or sections first, then call notify with a short error title and optional recovery text. Never dump raw API payloads into the toast; use autohide around 10 seconds when inline errors already own the recovery.

Success toasts use noun plus past participle with no trailing period, like "Voucher saved". Errors use "Couldn't" for user issues and "Failed to" for system issues, plus a short recovery sentence, matching the button verb that triggered the action.

Yes, the queue in notificationQueue.tsx shows a maximum of 3 toasts with FIFO overflow and dedupes by status plus title. Errors and toasts with action buttons stay sticky until dismissed, while success and info auto-dismiss after about 5 seconds.

Avoid toasts for billing or permission denials, multi-step triage, field validation, setup blockers, and narrating in-progress flows. These belong in banners, checklists, or inline UI; also aggregate bulk failures into one toast instead of one per row.