A vulnerability program is only as fast as the moment its people learn that something changed. A critical finding can sit unassigned for a day because nobody refreshed the right screen. An SLA can breach quietly because the owner never saw the warning. A scan can finish overnight and wait until morning standup before anyone acts on the new results. The work was done. The signal never arrived.
This is the gap that real-time security operations close. The platform already knows the instant a finding changes status, the instant a scan completes, the instant an SLA deadline passes. The question is whether that knowledge reaches the right human on the right channel within seconds, or whether it stays trapped in the database until someone goes looking for it.
PMAP treats delivery as a first-class concern. It runs a dedicated notification engine that fans events out to five channels, a Server-Sent Events transport that pushes live updates into every open browser tab, and an aggregation calendar that surfaces every time-sensitive obligation on one timeline. None of these features generate the events. They carry them. This article walks through how that carrying layer works, why each design choice matters for an operations team, and what it changes about the daily rhythm of a security program.
If you are new to the category, it helps to first understand the modern vulnerability management lifecycle, because notifications only make sense once you can see the finding journey they accompany. And if your goal is to remove repetitive manual work entirely, the companion piece on vulnerability management automation explains the rule and runbook engines that decide what should happen. This article is about what happens after that decision is made. The work is done. Now it has to be communicated, live.
Why Real-Time Visibility Changes Security Operations
Security operations have a latency problem that has nothing to do with the speed of any single tool. A scanner can finish in minutes. A correlation engine can deduplicate in milliseconds. A rule can reassign a finding the instant it lands. Yet the human response often lags by hours, because the humans are not watching the exact screen where the change occurred at the exact moment it happened.
Polling makes this worse, not better. Many platforms ask the browser to re-fetch a list every thirty or sixty seconds to look for changes. That model wastes bandwidth on the common case where nothing changed, and it still introduces a delay equal to the polling interval on the rare case where something did. A thirty-second poll means a critical event can wait up to thirty seconds before the screen even has a chance to reflect it, and that is before a person notices the refreshed pixel.
PMAP takes a different stance. The Realtime domain is described in the product as the platform’s push-notification backbone. It exposes a single Server-Sent Events endpoint that any authenticated browser tab connects to, then fans out live updates whenever domain events occur anywhere in the platform. A finding changes status, a scan finishes, a notification arrives, an asset is created, a report is ready. The browser learns immediately, without asking.
The operational effect is a shift from pull to push. Analysts stop hitting refresh. The notification bell increments the moment a finding is assigned, not on the next manual reload. A scan card flips from running to completed as soon as the import lands. A dashboard widget recounts assets without the user touching anything. The platform stops being a place you check and becomes a surface that updates itself while you watch.
This matters most under pressure. During an active triage push, the difference between a thirty-second polling delay and sub-second push is the difference between a queue that feels alive and a queue that feels stale. When an SLA is hours from breach, the warning needs to reach the owner now, on a channel they actually have open, not on a screen they last looked at this morning. Real-time delivery is not a cosmetic feature. It is the mechanism that makes a fast back end feel fast to the people who depend on it.
Five Delivery Channels in One Engine
The Notification domain is PMAP’s fan-out delivery engine. It receives events from the platform event bus and routes them to as many as five channels. Each channel exists because security teams do not all live in the same place, and a single event often needs to reach several of those places at once.
The five channels are the in-app bell, email, webhook, Slack, and Microsoft Teams. The in-app bell is a persistent, per-user inbox rendered inside the platform itself. Email is full HTML with a plaintext fallback, delivered over SMTP. Webhook is a server-to-server HTTP POST carrying a JSON envelope to an admin-configured URL, which lets you wire events into systems the platform does not natively speak to. Slack and Microsoft Teams both deliver rich messages through Incoming Webhooks, with Slack using Block Kit formatting and Teams using an Adaptive Card.
The reason to keep all five inside one engine rather than bolting on separate integrations is consistency. The engine receives a single event, evaluates which channels should fire for that event type and severity, and dispatches to each one with the same recipient logic. There is no risk that the email path and the Slack path disagree about who should be notified, because they read from the same source of truth. A finding assignment produces an in-app bell entry, an email to the assignee, and a Slack post to the assignee’s team from one coordinated pass, not three disconnected jobs.
Channel choice maps to how teams actually work. The in-app inbox is the system of record for anyone working inside the platform. Email is the durable, auditable channel that reaches people who are not logged in and creates a paper trail. Webhooks are the escape hatch for custom automation, on-call paging systems, or a SIEM that wants the raw event. Slack and Teams are where live operational chatter already happens, so pushing alerts into the channel an analyst already has open removes the need to switch contexts to learn that something needs attention.
The engine also recognizes which events have a severity and which do not. Findings and SLA events carry a severity. Scan and report events do not. As you will see in the section on rules, that distinction governs which alerts can be filtered down to the serious cases and which always pass through.
The In-App Inbox and Unread Counts
The in-app notification inbox is the most-used surface of the five, because every authenticated user has one and it lives inside the product they already have open. It is a per-user, cursor-paginated list of notifications with read and unread state, and it is filterable by read status and by event type.
Each notification row carries a type, an event type, a title, a body, and a small metadata map. That metadata is what makes the inbox actionable rather than merely informational. The data field carries identifiers such as the finding ID, scan ID, or approval request ID, so a click on a notification can deep-link straight to the entity it concerns. An analyst does not read “New Finding Assigned” and then go hunting for the finding. The notification knows which finding it is about and takes them there.
Above the inbox sits the unread count summary. This is a tiny but heavily relied-upon endpoint that returns the total and unread counts for the current user, which is exactly what the notification bell badge in the top bar needs to render. The badge is not a guess or an approximation. It reflects the real count of unread rows scoped to that user.
State management is deliberate and ownership-checked. A user can mark a single notification as read, and the platform enforces that only the target user can mark their own notification. A user can also mark all notifications as read in one operation, which clears the unread flag across every row they own. There is no way for one user to silence another user’s inbox, because every read operation is keyed to the caller’s identity.
The inbox is strictly single-tenant at the row level. Notifications are scoped to a user ID, and every list and summary query carries that scope derived from the user’s token. There is no cross-tenant notification delivery, and each user sees only their own rows. In a multi-tenant deployment this is not a configuration option to remember. It is an invariant of how the inbox queries are written, which is the kind of guarantee a multi-client operator needs before they trust a shared console.
The pagination model is worth a note for anyone building dashboards on top of it. The list uses cursor pagination based on an RFC3339 nanosecond timestamp, with a default page size of twenty-five. Cursor pagination keeps the list stable as new notifications arrive at the top, so an analyst scrolling through history does not get items shuffled or duplicated under them while fresh alerts land.
Team and Personal Channel Delivery
Slack and Microsoft Teams delivery in PMAP comes in two distinct forms, and understanding the split is important because they answer two different organizational questions.
The first form is team-channel delivery. Each team in the platform can store a Slack Incoming Webhook URL and a Teams Incoming Webhook URL on the team record. When an event is assigned to one or more teams, the engine posts a Block Kit message to each assignee team’s Slack URL and an Adaptive Card to each assignee team’s Teams URL. The rule is one post per assignee team per event. If a finding is assigned to two teams, both teams’ channels receive the alert in their own workspace. This is the channel for shared accountability. The whole team sees that a finding landed in their queue, in the chat space they already use to coordinate.
The second form is personal delivery. Individual users can store their own Slack or Teams Incoming Webhook URL in their profile and opt in to receiving alerts there. This is per-user and preference-gated, meaning a user controls whether their personal chat fires and for which event-and-channel combinations. Personal delivery is for the analyst who wants their own assignments to ping their own direct channel, independent of whatever the team channel does. The two forms coexist. A finding can post to the team channel for visibility and to the assignee’s personal channel for direct ownership, from the same event.
A practical design detail separates the team path from the rules engine. Slack and Teams team-channel delivery run independently of the admin rules. They fire to every assignee team that has a webhook URL configured, without needing a rule to enable them. This means assignment-driven chat alerts work as soon as a team has a webhook on file, and an administrator does not have to author a rule for every team to make team notifications flow.
SSRF Guarding Webhook Destinations
Any feature that sends a server-side HTTP request to a user-supplied URL is a potential Server-Side Request Forgery vector. If a platform will POST to whatever address a user types, an attacker who can set that address might coax the server into reaching internal services it should never touch. PMAP closes this door with strict host allowlisting on its chat webhooks.
Microsoft Teams webhook URLs must match the hosts that Microsoft actually uses for Incoming Webhooks, namely the patterns ending in webhook.office.com or webhook.office365.com. A Teams URL pointing anywhere else is rejected before any HTTP call is made. Slack personal-chat URLs are held to the same standard and must point to the official Slack webhook host. Invalid hosts never reach the network. The validation happens first, and the request is refused if the destination is not on the allowlist.
This is the right place to enforce the control, because it stops the bad request before it leaves the server rather than relying on downstream network policy to catch it. For a security product this is table stakes, and it is consistent with the broader principle that the platform never blindly trusts an externally supplied destination. If you want the deeper reasoning, the OWASP Server-Side Request Forgery Prevention Cheat Sheet is the standard reference for why allowlisting destinations beats blocklisting them.
There is one more safety property worth calling out. Personal and team chat dispatch each run on their own timeouts, and every chat and email failure is logged and swallowed rather than propagated. A notification failure must not break the finding or scan flow that triggered the event. If Slack is down, the finding still gets assigned and the in-app inbox still updates. The alert that could not be delivered is logged for diagnosis, but it never poisons the operation that produced it.
Multi-Assignee and Team Fan-Out
Real findings are rarely the responsibility of exactly one person. A vulnerability on a shared service might belong to two engineers and a team lead. A finding might be assigned to an individual for the fix and to a team for oversight. The notification engine handles this through fan-out, and it does so in a way that avoids the two failure modes that plague naive implementations: missed recipients and duplicate spam.
When an event carries an array of assignee user IDs, the engine fans the notification out to every user in that list for the in-app and email channels. Each assignee gets their own in-app row and their own email. Nobody is left out because the engine iterates the full list rather than notifying only the first or primary assignee. This is the property that makes shared ownership real. If three people are on the hook, three people get told.
At the same time, the engine deduplicates to prevent double-notification. If the same user appears in a way that would otherwise generate two notifications for one event, the engine collapses that to a single delivery. The principle that the product applies elsewhere holds here too. One real event should produce one notification per person per channel. Duplicate noise is removed before it ever reaches the inbox.
Team fan-out works on a parallel track. When an event carries an array of assignee team IDs, the engine fans out to each team’s Slack and Teams webhook. A finding assigned to four teams reaches four team channels. The user fan-out and the team fan-out are independent, which lets a single finding notify every individual assignee in-app and by email while simultaneously posting to every assignee team’s chat channel. The engine resolves all of this from one event in one coordinated pass.
The combined behavior matters for accountability. In a typical assignment, the person doing the work sees it in their inbox and their email, their team sees it in their shared Slack or Teams channel, and any custom system sees it via webhook if a rule is configured. Everyone who needs to know, knows, and nobody gets the same alert twice. That balance between coverage and restraint is exactly what keeps a notification system trusted rather than muted.
Notification Rules and Channel Preferences
Coverage without control becomes noise, and noise gets ignored. The fastest way to make a team stop trusting alerts is to send them everything. PMAP gives administrators and individual users two layers of control over what fires, so the volume stays meaningful.
The first layer is the admin rule engine. Platform administrators define rules that combine an event type, a channel, and an optional severity filter. A rule decides which channels activate for a given event type and supplies the static recipients or webhook URLs that channel needs. An administrator might create a rule that emails a fixed distribution list on every SLA breach, and a separate rule that POSTs every critical finding to an external webhook. Rules are the place where organizational policy lives. They answer the question of which categories of event deserve which channels at the platform level.
Severity filtering is the dial that keeps rule volume sane. A rule can carry a minimum severity threshold, and the engine evaluates severity as an ordered scale running from informational up through low, medium, high, critical, and urgent. A rule set to a high threshold activates only for high, critical, and urgent events, suppressing everything below. This is how a team subscribes a webhook to “only the things that matter” without writing custom filtering logic. The threshold does the work.
The engine also handles the events that have no severity sensibly. Scan and report events do not carry a severity, so they bypass the severity filter and always match. A rule that delivers scan completions does not accidentally suppress them because they lack a severity value. The filter applies where severity is meaningful and steps aside where it is not.
Rules also have a uniqueness guarantee that prevents accidental duplication at the configuration level. The system enforces a unique combination of event type, channel, and severity filter, so an administrator cannot create two conflicting rules for the same event-channel-severity triple. Attempting to create a duplicate is rejected. This keeps the rule table clean and makes the behavior of any given event predictable.
The second layer of control belongs to the individual user. Each user has a notification preference matrix that lets them opt in or out of specific event-and-channel combinations. A user who finds in-app sufficient for one event type can switch off email for it. A user who wants Slack only for assignments can tune exactly that. The engine consults the preference matrix on dispatch, so a personal opt-out is honored even when an admin rule would otherwise include that user’s personal address. The matrix supports both the current namespaced key format and the legacy keys, so existing preferences keep working as the system evolves.
The two layers compose cleanly. Admin rules set the organizational floor for what the platform sends and to which static recipients. User preferences let each person tune the channels that touch them directly. Team-channel chat delivery sits outside both, firing on assignment so shared visibility never depends on someone remembering to author a rule. The result is a system where the right alerts reach the right people on the channels they chose, and the firehose stays off.
Server-Sent Events: Live Push to the UI
Everything described so far concerns where a notification is delivered. Server-Sent Events concern how fast the open browser learns about any change at all, notification or otherwise. This is the live-push layer, and it is the reason the platform updates itself while you watch.
PMAP uses Server-Sent Events, a web standard built into browsers through the EventSource API. SSE is a one-way streaming protocol. The browser opens a single long-lived HTTP connection to the server, and the server pushes event frames down that connection whenever something happens. There is no polling loop and no message broker. It is a direct HTTP stream. For an authoritative description of how the transport behaves, the HTML Living Standard’s Server-Sent Events section is the source specification.
The platform exposes exactly one SSE endpoint. Any authenticated browser tab connects to it and receives a stream of JSON-framed events for the lifetime of that connection. Because EventSource cannot set custom headers, the endpoint accepts its authentication token either as a standard bearer header or as a query parameter, which is the accommodation that lets a plain browser connection authenticate properly. Once connected, the client receives an immediate ping so it can confirm the upgrade succeeded, then a comment heartbeat roughly every twenty seconds to keep the connection alive through proxies and load balancers that would otherwise time it out.
What flows down the stream is a curated set of domain events. The platform bridges finding lifecycle changes, scan completion, SLA breach, asset creation and update and deletion, project updates, report readiness, and notification events into the SSE stream. When a finding changes status, the finding list refreshes its status badge. When a scan finishes, the scan card flips to completed. When a notification is created, read, or marked all-read, the bell badge updates to match. The frontend routes every frame by its event type through a single handler, so one connection powers live updates across the whole interface.
The design is deliberately thin and deliberately safe. The Realtime domain owns only the transport. It does not produce events and it does not write to the database. Event production stays with the originating domains, and the transport simply relays selected events to connected clients. This separation means the push layer can be reasoned about and trusted on its own. It is a fan-out pipe, not a second source of truth.
Two engineering choices keep the stream healthy under load. First, each connection has a bounded buffer, and if a single client falls behind and its buffer fills, the platform drops that client’s lagging frame rather than blocking everyone else. One slow tab cannot stall the hub for every other connected user. Second, the stream is not persistent. Events that fire while a client is disconnected are not queued for later replay. The expectation is that a client performs a normal data refresh when it reconnects, picking up the current state from the regular API. This is the correct trade for a live-feed layer. It optimizes for sub-second latency on the connected case and leans on the durable REST surface to reconcile anything missed during a disconnect.
Scope filtering is enforced on every event the stream pushes. A platform administrator connection receives all events. Every other connection receives only events scoped to the companies that user has explicit access to, resolved at connect time. An event carrying no company scope is treated as a system-wide broadcast and reaches everyone. If the scope lookup fails for any reason, the connection is denied rather than defaulting to broadcasting everything. The system fails closed. In a multi-tenant deployment this guarantees that the live stream never leaks one tenant’s activity into another tenant’s browser, which is the same isolation principle the in-app inbox enforces, applied to the push transport.
A Unified Operations Calendar
Notifications and SSE handle the moment something happens. The calendar handles the obligations that are coming. It answers a different and equally important operational question. Not “what just changed” but “what is due, and when.”
The Calendar domain provides a unified, cross-domain event feed that surfaces time-sensitive items from across the platform on a single timeline. It does not own its own data. It is a read-only aggregation layer that queries projects, scans, findings, and framework agreements, then returns a sorted list of dated items within whatever window the caller asks for. One timeline, fed by four sources, sorted chronologically.
The items it surfaces are exactly the things a security operations team needs to see coming. Project start and end milestones. Scheduled and running scans. SLA deadlines for open findings. Retest-due dates for findings sitting in retest status. Framework agreement expiry dates. Each of these lives in a different domain and would otherwise require checking a different screen. The calendar pulls them onto one feed so the upcoming week, or month, or quarter, reads as a single picture rather than five separate ones.
The window is caller-controlled with sensible defaults. A request supplies a from and to date, and if either is omitted the platform defaults to roughly one month back and two months ahead, a three-month rolling view. That default covers the recently-overdue and the near-future in one query, which is the span an operations lead actually scans when planning the week.
The calendar also has a personal mode that changes what it returns in a meaningful way. When the request asks for the current user’s own items, the feed narrows to only the SLA deadlines and retest-due events where that user is a direct assignee, and it suppresses the company-wide project, scan, and agreement streams. This is what powers a personal calendar tab. An analyst sees their own deadlines and their own retest obligations without wading through every project milestone in the tenant. The same endpoint serves both the wide operational view and the narrow personal view, switched by a single parameter.
Three details make the calendar trustworthy rather than merely convenient. First, it respects the same terminal-status logic the finding domain uses, so SLA deadline items only appear for findings in open, non-terminal statuses. A closed or accepted-risk finding does not clutter the timeline with a deadline that no longer applies. Second, when a finding has multiple assignees, the SLA and retest queries deduplicate so the same deadline does not appear several times. Third, each item carries enough metadata, including the entity ID, entity type, severity, status, and company name, that a detail drawer can render the full context without a second request. Click an SLA deadline and the platform already knows which finding it is, how severe it is, and which tenant it belongs to.
Like the inbox and the SSE stream, the calendar honors tenant scope. A request can restrict to a single company, and personal mode filters to the calling user’s own assignments. The aggregation never crosses lines it should not cross. It reads from many domains, but it reads within the boundaries the platform enforces everywhere.
How Events Flow From Bus to Channel
It helps to trace one event end to end, because the three layers covered above are not three separate systems. They are three consumers of one event, and seeing the flow makes the architecture click.
It starts with a domain doing its job. A finding changes status, or a scan finishes its import, or an SLA deadline passes. The originating domain emits an event onto the platform’s in-process event bus. The event carries its type, its payload, and its tenant scope. The domain that produced it is done at that point. It does not know or care who consumes the event. It simply announces that something happened.
From the bus, two independent consumers pick the event up. The notification engine receives it, evaluates which of the five channels should fire based on the admin rules and the per-user preferences, resolves the recipients through the fan-out logic, and dispatches to the in-app inbox, email, webhook, Slack, and Teams as appropriate. In parallel, the realtime bridge relays the event into the SSE hub, which pushes it down to every connected browser whose scope includes the event’s tenant. The same status change that creates an in-app row, an email, and a Slack post also flips the status badge live in every open tab.
A crucial property of this flow is that delivery is asynchronous and isolated from the originating operation. The notification engine processes events in the background, using its own context rather than the request that triggered the event, so a slow SMTP server or an unreachable Slack workspace cannot stall the finding update that started everything. Each email recipient and each webhook target gets its own dispatch, so one slow destination does not delay the others. And every delivery failure is logged and contained. The finding still saves. The scan still imports. The alert that failed is recorded for diagnosis, not allowed to break the work.
This is the architectural reason the platform can feel both fast and reliable at once. The expensive, failure-prone parts, which are the outbound network calls to email and chat, are pushed to the background and isolated per recipient. The cheap, reliable parts, which are the in-app row write and the SSE push, happen quickly. The originating domain never waits on any of it. The event fires, the work commits, and delivery happens out of band.
The same pattern explains why the calendar is a separate concern from the notification and SSE layers. The calendar does not subscribe to the event bus at all. It is a read-time aggregation that queries the current state of projects, scans, findings, and agreements when someone opens the calendar view. Notifications and SSE answer “tell me the instant this changes.” The calendar answers “show me what is scheduled.” Together they cover both the reactive and the proactive halves of operational awareness.
How PMAP Keeps Operations Live
Pulling the threads together, PMAP keeps a security operation live through three coordinated layers, each with a clear and limited job.
The notification engine is the delivery layer. It takes one event and fans it out to as many as five channels, in-app, email, webhook, Slack, and Teams, with multi-assignee and multi-team fan-out, deduplication, admin-defined rules, severity filtering, and per-user preferences. It guards its outbound destinations with host allowlisting, isolates every dispatch so failures stay contained, and scopes every inbox strictly per user. This is where an event becomes a message that reaches a human.
The Realtime domain is the push layer. A single Server-Sent Events stream delivers live updates to every open browser tab, refreshing finding badges, scan cards, dashboard counts, report indicators, and the notification bell the instant the underlying event fires. It is intentionally thin, owns only the transport, enforces tenant scope on every frame, fails closed on scope errors, and survives slow clients without stalling the rest. This is where the back end’s speed becomes visible speed.
The calendar is the planning layer. It aggregates SLA deadlines, retest obligations, scan activity, project milestones, and agreement expiries onto one chronological timeline, with a personal mode that narrows the view to a single user’s own obligations. This is where a team sees what is coming rather than only what just happened.
None of these layers invent the events they carry. They are the communication tissue around a platform that already knows what changed. That separation is the point. The domains that own findings, scans, and assets stay focused on being correct. The delivery, push, and aggregation layers stay focused on being fast and reaching the right people. The result is an operation where nothing important waits in a database for someone to go looking. The finding gets assigned and the assignee knows within seconds, on the channel they chose, while their dashboard updates itself and their calendar already shows the deadline that fix has to beat.
If automation is your next step, the rules and runbooks covered in vulnerability management automation decide what should happen to a finding, and the notification engine described here carries the result to your team. And to see how the whole journey fits together from intake to closure, the vulnerability management lifecycle is the wider map. For a focused product summary of the delivery layer itself, the notifications and real-time operations datasheet lays out the channels, the SSE transport, and the calendar in one reference.
You can also explore the deeper mechanics in the cluster guides on the event bus, server-sent events, notification rules, and the operations calendar, or read the day in the life of a VM analyst to see how these layers feel in practice.
Frequently Asked Questions
What notification channels does PMAP support?
PMAP delivers notifications across five channels from one engine. The in-app bell is a persistent per-user inbox inside the platform. Email is HTML with a plaintext fallback over SMTP. Webhook is a server-to-server HTTP POST to an admin-configured URL. Slack delivers a Block Kit message through an Incoming Webhook, and Microsoft Teams delivers an Adaptive Card the same way. A single event can fire to several of these channels at once based on the configured rules and each user’s preferences.
How does PMAP deliver real-time updates without polling?
PMAP uses Server-Sent Events, a standard browser streaming protocol exposed through the EventSource API. Each authenticated browser tab opens one long-lived connection to a single SSE endpoint, and the platform pushes JSON event frames down that connection the instant a domain event occurs. Finding status changes, scan completions, SLA breaches, asset changes, and notification events all flow through this one stream, so the interface updates itself in real time rather than re-fetching on a timer.
Can users control which notifications they receive?
Yes, through two layers. Platform administrators define rules that combine an event type, a channel, and an optional minimum severity threshold, which sets the organizational policy for what the platform sends and to which static recipients. Individual users then tune a personal preference matrix that opts them in or out of specific event-and-channel combinations. The engine consults the user’s preferences on dispatch, so a personal opt-out is honored even when an admin rule would otherwise include that user.
How does PMAP prevent duplicate or missed alerts when a finding has several owners?
The notification engine fans an event out to every assignee in the recipient list, so no owner is skipped, and it deduplicates so the same person does not receive two notifications for one event. User fan-out for in-app and email runs independently of team fan-out for Slack and Teams, which means a finding can reach every individual assignee directly and every assignee team’s shared channel at once, without anyone getting the same alert twice.
Is the notification and real-time system safe for multi-tenant deployments?
Yes. The in-app inbox is scoped strictly per user, and every list and summary query carries that scope, so no user sees another user’s notifications. The SSE stream enforces tenant scope on every frame. Platform administrators receive all events, every other user receives only events for companies they have explicit access to, and a scope lookup failure denies the connection rather than broadcasting everything. The system fails closed, so tenant isolation holds on both the inbox and the live stream.
What does the operations calendar show?
The calendar aggregates time-sensitive items from across the platform onto one chronological timeline. It surfaces SLA deadlines for open findings, retest-due dates, scheduled and running scans, project start and end milestones, and framework agreement expiry dates within a caller-chosen window that defaults to roughly three months. A personal mode narrows the feed to only the calling user’s own SLA deadlines and retest obligations, which powers a personal calendar tab without showing every company-wide item.
What happens to a notification if Slack or email is down?
The originating operation is never affected. Notification delivery runs asynchronously in the background using its own context, and every email and chat dispatch is isolated, so a slow or unreachable destination does not stall the finding update or scan import that triggered the event. Delivery failures are logged for diagnosis and contained rather than propagated. If a chat channel is unreachable, the finding still gets assigned and the in-app inbox still updates, so the core work always completes even when an external channel fails.
