Notifications

Overview

OrgGuard sends email notifications when policies evaluate assets and generate findings. Every notification is recorded in the Notification object (Notification__c) — what was sent, to whom, when, and whether delivery succeeded. This page covers reading that record, diagnosing failures, and configuring delivery behavior.

Each Notification__c record has a Notification Type of either Email or InApp — that’s the channel the record represents, not who it goes to. Routing (whether an alert goes to the asset’s owner, the admin group, or both) is decided by the originating policy’s Step 4 — Notification Settings toggles, not by a stored type:

• Notify Asset Owner (toggle) — when on, the asset’s assigned Owner (the Salesforce user’s email) is notified when their asset triggers a finding.
• Notify Admin Group (toggle) — when on, the address configured in the policy’s Admin Group Email field is notified.

Deduplication is per-policy (the Deduplication Window set on the policy wizard’s Step 4), so repeat alerts for the same finding are suppressed for N hours.

Email delivery is batched into a per-recipient digest. The Notification Scheduler runs hourly; each time it fires, OrgGuard groups the pending email notifications by recipient (up to 100 records per fire, oldest first) and sends one summary email per recipient — a finding count plus a severity breakdown and a View in OrgGuard link to the Notifications tab. It does not send one email per finding, and there is no acknowledge link in the email. The per-finding Notification__c records are still created one-per-finding (and so are the in-app bell alerts); only the email send is aggregated. Open the Notifications tab from the email to see each finding’s record.

Who this page is for

Admins investigating why a notification did or didn’t arrive, or building reports off delivery history. For configuring which findings generate notifications, see Policies → Notification Settings.

---

What you’ll see

The Notifications tab shows a paginated table of Notification__c records, newest first. Each row represents one attempted delivery. The page has:

• A Status filter (All / Pending / Sent / Failed / Suppressed) above the table.
• A Refresh button in the card header.
• 25 rows per page with Previous / Next pagination controls below the table.
• A View button on each row that opens the full notification record.

Key fields on each record:

Field	Meaning
Notification Type	Email or InApp — the delivery channel. Who receives it is set by the policy’s Step 4 toggles, not this field
Subject	The email subject line
Body Summary	A short excerpt of the email body
Recipient	The destination email address
Status	Pending, Sent, Failed, or Suppressed
Sent At	Timestamp of successful delivery (blank while Pending or Failed)
Finding	Lookup to the Finding__c record that triggered this alert
Error	Populated only when Status is Failed — contains the Apex or Messaging error text

Notification__c is a normal custom object, so you can still build custom list views, report types, and filters using the standard Salesforce tools — navigate to Setup → Object Manager → Notification for list-view and reporting setup, or use Reports with a report type based on the Notification object. The tab itself is an OrgGuard app page rather than a raw object list view.

---

Common tasks

Task: Verify a specific notification was sent

Who can do this: OrgGuard User (read access to Notification__c).

1. Open the Notifications tab.
2. Set the Status filter to Sent. Rows are ordered newest first, so recent deliveries are at the top; scan the Recipient column for the expected address (use Next to page through if needed).
3. Expected result: one row per delivery attempt with Status = Sent and a populated Sent At timestamp.

If no row exists for the expected recipient/time, either:

• The policy that should have fired had Notify Asset Owner / Notify Admin Group disabled, or
• Deduplication suppressed the send (the previous identical alert was within the dedupe window).

Task: Diagnose a failed delivery

1. Open the Notifications tab.
2. Set the Status filter to Failed.
3. Click View on the failed row to open the record.
4. Read the Error field — common causes are listed in Troubleshooting below.
5. Fix the underlying cause (bad recipient address, email deliverability off, etc.).
6. OrgGuard does not auto-retry failed sends. To re-send, acknowledge or suppress the source finding and re-open it to re-trigger policy evaluation on the next scan.

Task: Configure per-policy notification routing

Notifications are routed per policy, not globally. To change who gets alerted for a given policy’s findings:

1. Open the Policies tab.
2. Open the Actions menu on the relevant policy → Edit.
3. Advance to Step 4 — Notification Settings.
4. Adjust:
   • Notify Asset Owner (toggle) — when on, sends to the asset’s assigned Owner (their user email).
   • Notify Admin Group (toggle) — when on, reveals and sends to Admin Group Email.
   • Deduplication Window (hours) — minimum hours between repeat sends for the same finding.
5. Save the policy.
6. Expected result: the next scan uses the new settings.

See Policies for the full wizard walkthrough.

Task: Raise the dedupe window to reduce alert fatigue

If recipients are complaining about repeat emails:

1. Identify the offending policy — the recipient can tell you the Subject line; match it to a policy.
2. Edit the policy; advance to Step 4.
3. Raise Deduplication Window (hours) from the default 24 to something larger (e.g. 72).
4. Save.
5. Expected result: the same finding won’t trigger repeat sends within the new window. The finding itself still updates.

Task: Confirm org-level email is enabled

Before OrgGuard can send anything, Salesforce must allow outbound email:

1. Open Setup → Email Administration → Deliverability.
2. Set Access Level to All email.
3. Save.

Sandboxes default to System email only — remember to re-enable after a refresh.

Task: Configure the sender address

Who can do this: OrgGuard Admin (read/edit on OrgGuard_Setup__c.OrgWide_Email_Address_Id__c).

By default, OrgGuard notifications are sent on behalf of whichever user owns the scheduled job — fragile and bad for deliverability. Override this with a verified Org-Wide Email Address (OWEA) for two reasons:

1. Deliverability — messages from a domain you control can be DKIM-signed by Salesforce, which stops Gmail and Microsoft 365 from flagging alerts as unverified (“Be careful with this message — couldn’t verify this”).
2. Continuity — without an OWEA, alerts stop the moment the scheduling user leaves the org or has their license deactivated. An OWEA decouples From-address from any individual.

Prerequisites: Salesforce admin access (to create the OWEA), DNS access for the OWEA’s domain (to set up DKIM later).

1. Setup → Email → Organization-Wide Email Addresses — create a new address (e.g. notifications@example.com) and click the verification link Salesforce mails you.
2. Open the OrgGuard Setup Wizard and advance to Step 5: Email Notifications (or revisit it if setup is complete).
3. Pick the verified address from the Org-Wide Email Address dropdown.
4. Click Send Test Email — OrgGuard sends a test message to your own login address using the same path as real notifications, so if it arrives in your inbox, real alerts will too.
5. Advance through the wizard so the choice is saved (or click Save if you are revisiting).
6. Expected result: subsequent Notification__c records send with the OWEA in the From line. Confirm in Gmail’s “Show original” — From: matches the OWEA and Authentication-Results shows the DKIM/SPF state of your domain.

Pair the OWEA with DKIM for full alignment

Selecting an OWEA gets you a stable, branded From address — but Gmail and Workspace will still flag the message as unverified unless your domain is DKIM-signed by Salesforce.

After picking the OWEA:

1. Setup → Email → DKIM Keys → Create New Key
2. Use the OWEA’s domain (e.g. notifications.example.com or the parent domain example.com).
3. Add the two CNAME records Salesforce gives you to your DNS.
4. Wait ~1 hour for DNS propagation, then activate the key in Salesforce.

Once active, alerts arrive with d=yourdomain DKIM signatures and Gmail’s “couldn’t verify” warning disappears.

Caution

If you clear the OWEA selection (set OrgGuard_Setup__c.OrgWide_Email_Address_Id__c to blank), OrgGuard silently falls back to the running user’s address. This is intentional — backward-compatible with installs that haven’t configured an OWEA yet — but it can mask the loss of branding if an admin clears the field by accident.

---

Status reference

Status__c	What it means	Typical cause
Pending	Queued but not yet sent	Transaction still in flight — usually visible for < 1 second
Sent	Messaging.sendEmail succeeded	Delivery is Salesforce’s problem from here; SMTP retries happen behind the scenes
Failed	Send attempt raised an exception	See Error field — deliverability off, invalid recipient, etc.
Suppressed	OrgGuard chose not to send	Dedupe window suppressed the send, or Recipient was blank

---

Troubleshooting

Symptom	Likely cause	Fix
Recipient swears no email arrived, but Status = Sent	Message reached SMTP; landed in spam or flagged as unverified by Gmail / Microsoft 365	Ask recipient to check spam/junk. For a durable fix, configure an Org-Wide Email Address on a domain you control and pair it with DKIM signing — this stops mail providers from flagging alerts as impersonated.
Status = Failed, Error mentions “Email deliverability”	Org Deliverability set to System email only or No access	Setup → Email → Deliverability → set to All email.
Status = Failed, Error mentions “SINGLE_EMAIL_LIMIT_EXCEEDED”	Daily mass-email limit hit (5,000/day for most editions)	Reduce scan frequency, raise the dedupe window on noisy policies, or contact Salesforce about limits.
Status = Failed, Error mentions “INVALID_EMAIL_ADDRESS”	The Admin Group Email on the policy is malformed	Fix the Admin Group Email on the policy. (Owner notifications use the assigned user’s Salesforce email, which is always well-formed.)
Admin group didn’t receive expected alert	Notify Admin Group toggle off, or Admin Group Email blank	Edit the policy; turn on the toggle and fill in the email.
Repeated digest emails across scheduler fires	Deduplication Window too low, or distinct policies each send (not deduped across policies)	Within a single scheduler fire each recipient gets one digest; repeats across fires mean the source findings re-triggered. Raise the dedupe window on the policy; if multiple policies fire on the same asset, consider consolidating into one policy.
No Notification record exists for a finding	The policy has both Notify toggles off	Edit the policy; enable at least one Notify toggle.
Error column is blank but delivery is stuck in Pending	Transaction failed and was rolled back before Sent At was written	OrgGuard Admin: find the corresponding entry in Diagnostic Logging for the scan run. Others: ask your admin to check the Diagnostic Log Viewer, or email support@orgguard.com with the Notification record’s name and timestamp.

---

FAQ

Does OrgGuard retry failed notifications automatically? No. Failed Notification records stay in Failed status with the Error populated. To re-send, fix the cause and re-trigger the source finding (reopen → re-evaluated on next scan).

Can I customize the email template? Not in OrgGuard Pro 1.0. The digest email is generated by OrgGuard’s EmailService; each Notification__c record’s Subject and Body Summary fields are set by NotificationDispatcher. Templated emails with branding are planned for a future release.

What stops OrgGuard from sending during deduplication — the finding or the notification? The finding still updates and remains active — only the email send is suppressed. A Notification record with Status = Suppressed is created so you can see that dedupe triggered.

Why did one finding notify the owner and another notify the admin group? Routing depends on the policy’s Step 4 toggles. A single policy can notify both the asset owner and the admin group for each finding, just one, or neither. This is a policy routing decision, not a stored Notification Type (which only records the channel — Email or InApp).

I got one email summarizing several findings instead of one email per finding — is that intentional? Yes. Each Notification Scheduler fire sends one digest email per recipient: a count of findings needing attention, a severity breakdown, and a link to the Notifications tab. This prevents inbox floods when a scan surfaces many findings at once. Each finding still has its own Notification__c record — open the Notifications tab to review and act on them individually.

Is there a test-send feature? Yes. In Step 5: Email Notifications of the Setup Wizard, click Send Test Email — OrgGuard sends a delivery test to your own login address using the same sender path as real notifications. See Configure the sender address for the walkthrough. To exercise the full policy-to-notification path instead, create a throwaway asset with a known-expiring date, enable a test policy targeting it with a short dedupe window, run a scan, and verify the Notification record and delivery; delete the asset when done.

Can notifications trigger Slack / Teams / PagerDuty? Not directly — OrgGuard sends email only. Bridge to other channels via Salesforce Flows on Notification__c insert (send to an external endpoint) or forwarding rules on the Admin Group inbox.

Can I delete a notification record? No. Notification records are delivery evidence — deletion is blocked at the platform level regardless of permission set or profile. They are purged automatically by the data-retention policy. To reduce noise, suppress the source finding (set Status = Suppressed on the Finding__c record) or raise the Deduplication Window on the originating policy.

---

Related

• Policies — wizard Step 4 configures who, how, and how often
• Findings — the records that trigger notifications
• Diagnostic Logging — capture detailed error context when sends fail
• Scheduled Jobs — when scans run, which is when notifications fire
• Permission Sets — who can read and edit Notification__c