Notifications and delivery

Task and prerequisites

Use this guide to route a supported workspace event or investigate a missing message. You need authorized notification settings access, a supported configured destination and the applicable event rule.

The recipient must be authorized to open the linked record. A report schedule, audit schedule and external-delivery rule are different controls; none implies that every channel receives a message.

In-app notifications

In-app notifications draw attention to workspace events and related records. Open the linked audit, connection, or action to inspect its current state before responding.

The underlying condition may have changed since the notification was created. Marking a notification read or archiving it organizes the inbox; it does not resolve an unhealthy connection, approve work, or verify savings.

Keep follow-up decisions in the relevant record so other reviewers can see their outcome.

External delivery receipts

External messages have separate delivery receipts. A queued message is waiting for delivery.

An attempt records that delivery was tried; an accepted HTTP request confirms acceptance by the destination service, not that a person read the message. Microsoft Teams workflow acceptance can still leave channel rendering unconfirmed.

An in-app notification does not establish email, Teams, Slack, or webhook receipt. Check the receipt for the configured destination before relying on an external message for coordination.

Choose supported destinations and rules

Notification settings use named destinations and explicitly selected event rules. Rules are disabled by default; configuring a destination alone does not enable every event.

Use the destination types and routing options offered in the current screen. Notification rules and general integrations have different supported destinations, so the presence of an integration does not promise support in every notification workflow.

Unsupported digest, quiet-hours, severity, reminder, or escalation options must not be treated as active automation.

Preview and inspect the result

A configuration preview shows intended content without sending a message. Fixture or disabled outcomes also do not establish live delivery.

After a supported send, inspect the receipt and, where necessary, the destination channel or workflow. Review links still require normal sign-in and authorized workspace access.

Sending a link cannot grant the recipient a role or access to another organization's records. Confirm recipient setup before relying on a review notification.

Handle failures without duplicate messages

Follow the receipt's retry guidance after a failure. An uncertain outcome may be marked for no resend because the destination could already have accepted the message.

Repeated tests can create duplicates and should not replace checking the channel or workflow. Ask support to investigate with the safe failure category and receipt reference if needed.

Keep destination credentials, private payloads, and signing secrets out of support messages and shared screenshots.

Steps and expected result

Confirm the destination and selected event, inspect the preview and enable only the permitted rule. After an actual supported send, open its receipt and related record.

Check the destination workflow if rendering or receipt is unconfirmed. Expected evidence distinguishes queued, attempted, accepted, uncertain and failed delivery; marking the in-app item read only changes inbox state.

A local fixture send or successful provider request is not proof of an inbox receipt.