BryanNet

Notifications and customer communication

Prerequisites and authority

Use an individual staff account with the action permission and required organization module/license. Viewing a menu does not establish permission to mutate records.

Interpret and manage notifications

Administration → Notifications shows administrator-facing notifications. Customer notifications and delivery channels are a related but separate workflow. Use available filters and read/history controls to inspect the event rather than assuming it is a live alarm.

Confirm who the notice targets, which event generated it and whether it describes business state or delivery failure. A failed Telegram message does not establish that subscription activation failed.

For planned work, use the supported communication route and a manual notice where needed. Do not assume this screen contains a scheduled broadcast facility. Planned maintenance windows and notifications covers the content and timing of maintenance notices.

Customers have in-app notification history and Telegram delivery according to the supported configuration. The current scope does not include customer category opt-outs or browser/OS push while the application is closed. An unread count is different from a delivery acknowledgement.

After changing notification configuration, trigger one safe test event and inspect both in-app history and the external delivery result. Avoid generating real expiry/disconnection events against production customers just to test a message. Keep sample records free of credentials and personal data before capturing screenshots.

Related guides

Related guides: Staff accounts, roles and permissions, Administrative session and audit investigation, System operations and task controls, Roles and permission matrix.