Notifications
Which notifications reach the phone, how to choose types, what Apple and Google see, and what if push is off or buff.systems is unreachable.
The app tells you what is waiting for you even when it is closed: an answer to a question is ready, a formulation awaits approval, a review is needed, a Buff Code agent is waiting for permission. Tapping a notification opens the right screen — the task, the thread or the session.
What arrives
- From an installation (buff.systems, Buff Community, Enterprise) — the same events as in the workspace’s bell: clarifying questions and approval, review, merge conflicts, task publishing, answers and questions in “Ask”, finished research, failures. By default the events that require your action or that you are waiting for are switched on.
- From Buff Code — the agent is waiting for permission, has asked a question, has finished its turn, has failed with an error. No more than once a minute for the same event in the same session, and not to the phone on which that session is currently being viewed.
All notifications are collected in the app under “Notifications” (in the side menu, with an unread counter): the “Unread” filter, “Mark all as read”.
Choosing types
Types are chosen for each installation separately and for this phone: “Settings → Installations → installation → Notifications”. This is for a workspace (buff.systems, Buff Community, Enterprise); a machine with Buff Code sends its four events without a choice of types. The switches are grouped as in the workspace’s notification settings; a group can be switched on or off as a whole. The installation stores the choice, so your other phones and the workspace’s browser notifications stay as they were.
If the system has forbidden the app to show notifications, the settings screen says so and offers to open the system settings.
What Apple and Google see
Notifications to the phone are delivered by Apple (APNs) and Google (FCM) — otherwise a closed app cannot be woken. That is why the notification text is encrypted for your phone already on the installation: buff.systems, Apple and Google pass on only an encrypted package and do not know what it is about. The app on the phone decrypts and shows the notification itself. More in What buff.systems sees.
A phone without Google services
On Android, notifications are delivered by Google (FCM). On phones without Google services — for example, Huawei with AppGallery — the app works fully, but push does not arrive: what is waiting for you is visible under “Needs attention” on the home screen and in the sections.
If push is turned off
In Buff Community and Enterprise the administrator can turn off push notifications (the “Mobile app” section of the admin panel, “Push notifications → Off”). Then no notifications reach the phone, and what is waiting for you is visible in the app on the home screen under “Needs attention” and in the sections.
An installation without access to buff.systems
The phone and the installation meet at the buff.systems gateway — the phone has no direct route into your company’s network, and the network does not need to be opened to the outside. That is why the installation needs outbound access to buff.systems. A fully isolated (air-gapped) installation cannot connect to the app; the workspace in a browser inside the network works as usual.
Several installations
How the app holds several installations at once, what their statuses mean, and what happens when an installation or the network is unavailable.
What buff.systems sees
The app’s trust model in plain words: end-to-end encryption, what passes through the buff.systems gateway, Apple and Google, what is stored on the phone.