A redacted proof packet for sandbox email risk

This example uses demo metadata only. It shows the object Silobase gives a Salesforce admin or consultant: path counts, recipient class, unresolved coverage, and the safe-test actions to finish before UAT email is opened.

silobase - demo scan / redacted proof
SourceSenderRecipient classRiskRelease note
FlowWorkflow contextReal-contact riskHighWould-send path needs containment before UAT deliverability opens.
ApexSingleEmailMessageExternal literalHighLiteral address stays redacted; owner must confirm it is test-safe.
ApprovalApproval alertUnparsed endpointReviewCoverage gap is visible instead of hidden behind a green result.
Org-wide senderSandbox senderSender configReviewSender identity is checked before anyone treats the path as safe.
Redacted manifest

Show the risk shape without showing private metadata

The proof packet keeps the row-level object a release owner needs, but replaces raw addresses and org details with recipient classes. A consultant can still point to the risk mix, source type, sender class, and unresolved endpoints.

  • 8 email paths from demo metadata
  • 2 free-preview findings and 6 gated report findings
  • No raw email addresses, org IDs, tokens, or customer metadata
Read how rows are mapped

Risk mix

Demo scan / redacted counts

Unparsed endpoints3
External-address risk2
Real-contact risk2
Org-wide sender1
Coverage gaps

Unparsed paths stay visible

The demo scan does not pretend every branch is solved. Approval-process endpoints, literal Apex addresses, and sender configuration gaps stay on the page with a manual-review note, so the release team can decide before deliverability changes.

  • Apex is treated as heuristic static review, not full symbolic execution
  • Manual-review rows block clean sign-off until someone owns them
  • Resolved and unresolved paths can both appear in the same proof packet
Check deliverability rules

Source coverage

Detected paths by metadata family

Flow3
Email alert2
Approval1
Apex1
Org-wide sender1

Three paths require manual review before anyone signs off the sandbox for UAT.

Unparsed endpoints are kept in the proof packet
Safe-test plan

Every finding maps to a next action

The paid report should not be a wall of warnings. It turns the manifest into a contained test plan: check the sender, inspect the recipient class, retest after the fix, and keep the result on the release ledger.

  • Review approval alerts whose recipient endpoint could not be parsed.
  • Inspect Apex SingleEmailMessage paths for literal addresses before UAT.
  • Confirm org-wide senders point to intentional sandbox-safe identities.
  • Retest after metadata changes and save the result as release evidence.
See release evidence

Safe-test actions

What the release owner does next

1

Review approval alerts whose recipient endpoint could not be parsed.

2

Inspect Apex SingleEmailMessage paths for literal addresses before UAT.

3

Confirm org-wide senders point to intentional sandbox-safe identities.

4

Retest after metadata changes and save the result as release evidence.

Retest result becomes a release-ledger row.
Saved with the paid report or recurring ledger

What this demo proof packet contains

8
email paths mapped from fixture metadata
3
unparsed endpoints left for manual review
0
raw addresses or org identifiers exposed here

Proof boundary

What this page does not claim

This is not an official Salesforce artifact. It is not a guarantee that no email can send. It is a redacted example of how a metadata scan becomes release evidence.

Not affiliated with Salesforce

No guaranteed prevention claim

No raw customer metadata

No full Apex symbolic execution claim

Turn your own sandbox export into a proof packet.

Upload metadata, inspect the first findings free, then decide whether the $99 report or $39/mo ledger belongs in the release process.

    Sandbox Email Proof Example — silobase — silobase