Unified Notification Center Automation: Every Update Type in One Place, Push That Respects the Clock
Why several kinds of updates need one consistent home, not five separate ones
A single team’s day touches several genuinely different kinds of events — someone needs to approve a deliverable, a client raised a ticket, a task is due, an invoice needs attention, a scheduled post went live. Each of those could, in principle, get its own separate notification mechanism, but that just multiplies the places someone has to check and the chances something gets missed. Centriu Axis treats these as variations of one underlying concept — a notification with a type, a read state, and a destination — rather than as five unrelated systems bolted together.
How the underlying problem shows up before you fix it
An approval request and a billing notice show up in completely different places, so checking "what needs my attention" means checking several separate systems.
A notification’s read state is inconsistent — marking one as read somewhere does not reliably reflect that state everywhere it might show up.
Push notifications fire regardless of the time of day, including the middle of the night, because nothing accounts for when a person actually wants to be interrupted.
There is no single unread-count badge reflecting everything that actually needs attention across ticket updates, approvals, tasks and billing at once.
A notification type introduced for one workflow (say, publication results) has no clear place to live inside a system built only around a different type (say, tickets).
Why this keeps happening without a unified notification engine
Building a separate notification mechanism for each workflow (approvals, tickets, tasks, billing, publishing) is the path of least resistance when each feature is built independently, but it leaves no single, consistent place for someone to check what needs their attention, and no consistent rule for read-state or delivery timing. Without a single engine underneath all of them, "did I already see this" and "should this wake someone up at 2am" get answered differently — or not at all — for each type.
How Centriu Axis consolidates notifications and respects quiet hours
Axis’s notification engine handles eight distinct types — approval requests, approval reminders, messages, ticket updates, task updates, billing (boleto), publication results, and system notifications — through one consolidated table with a coherence mechanism ensuring the read/unread state stays consistent everywhere it is checked, backed by a unified notification center in the app and a badge reflecting the real unread count. Delivery goes out through Web Push and native push (Android and iOS, the latter dependent on external push-certificate configuration), and an organization can configure a quiet-hours window — defaulting to 8pm–8am — during which push delivery is suppressed for that time range, without preventing the notification from still being recorded and visible in-app when the person next checks.
What is actually built today
Eight notification types handled through one consolidated engine: approval requests, approval reminders, messages, ticket updates, task updates, billing (boleto), publication results, and system notifications.
A read-state coherence mechanism keeping the unread/read status consistent across the app.
A unified notification center with an accurate unread-count badge.
Web Push and native (Android/iOS) push delivery.
A configurable quiet-hours window (default 8pm–8am) that suppresses push delivery without suppressing the in-app notification itself.
A team member checking notifications after a busy day (illustrative scenario, not a real client)
Over the course of the day, a team member accumulates several different kinds of notifications: a client approved a deliverable, a new client ticket came in about a deadline, and a task became overdue. All three show up in the same unified notification center, each clearly typed, rather than requiring a check across three separate systems.
At 9pm, a new ticket comes in from a different client. Because the organization’s quiet-hours window runs from 8pm to 8am, no push notification fires that night — but the ticket is still recorded and shows up, unread, in the notification center and badge count the next morning.
When the team member opens the notification center and reviews the ticket, its read state updates consistently everywhere it appears in the app — there is no separate place where it might still show as unread.
What changes operationally
The structural change is one consistent place to check what needs attention across every kind of update, with push delivery that respects a defined quiet-hours window rather than firing regardless of the time. What that is worth in reduced missed updates or fewer after-hours interruptions depends heavily on a team’s own workflow mix and notification volume — Centriu does not attach a specific figure that would generalize.
When this is not the right fit
A very small team handling only one or two of these notification types, with low enough volume that informal tracking already works, may see less specific value from a unified notification center.
Separate notification mechanisms per workflow vs. one unified center
Building a separate notification mechanism for each workflow — approvals here, tickets there, billing somewhere else — leaves no single place to check what needs attention and no consistent rule for delivery timing. Centriu Axis’s unified notification center handles all eight types through one engine, with a consistent read state and a configurable quiet-hours window that governs push delivery uniformly, not per feature.
Related systems
Main system: Centriu Axis.
What it does NOT do
- Does not guarantee push delivery on every platform under every condition — iOS push specifically depends on external push-certificate (APNs) configuration outside the app itself.
- Does not suppress in-app notifications during quiet hours — only push delivery is suppressed; the notification is still recorded and visible when checked.
- Does not let a notification type be added without engineering work — the eight types are the ones currently built; a new category is not user-configurable.
- Does not merge notification data across different organizations using Axis — each account only sees its own.
Security and governance
Each organization using Centriu Axis only sees its own notifications and push subscriptions — nothing is shared across accounts. Personal data referenced in a notification follows Brazil’s LGPD (Law No. 13,709/2018). Full detail on access control and audit trails lives at /governanca and /iso.
Pricing and contracting
Included at no extra cost with any Centriu contract. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
What notification types does the unified center handle?
Eight: approval requests, approval reminders, messages, ticket updates, task updates, billing (boleto), publication results, and system notifications.
What is the default quiet-hours window?
8pm to 8am, and it is configurable per organization.
Does quiet hours stop the notification from being recorded, or just the push alert?
Just the push alert — the notification is still recorded and appears in-app when next checked.
Is push delivery guaranteed on every platform?
Web Push and Android are confirmed; iOS push delivery specifically depends on external push-certificate configuration, so it is not guaranteed on every setup.
Does marking a notification as read update consistently everywhere?
Yes — a coherence mechanism keeps the read/unread state consistent across the app.
What does Centriu Axis cost?
Axis is included free with any Centriu contract — it has no separate paid plan.
See how Centriu Axis’s unified notification center works
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.