Report a Problem

Every page in the portal (admin and client side) has a Report a Problem button in the header. It opens a modal where the person reporting can describe what went wrong, attach screenshots, or talk the issue through with their voice.

Use it when something looks broken, a number is wrong, an email didn't arrive, or anything else where you'd otherwise file a support ticket.

What gets sent

The submission packages four things:

• The message typed (or transcribed from voice) by the reporter.
• Up to 5 screenshots the reporter attached, each up to 5MB.
• The page URL the reporter was on when they clicked Report a Problem.
• Their account context (admin email + org, or client email + customer record) so the recipient can find the affected record quickly.

The submission goes out as an email via Resend to a configurable address.

Who receives the report

Set the PROBLEM_REPORT_EMAIL environment variable to the address you want submissions routed to. If unset, it falls back to your org's ADMIN_EMAILS list, then to the platform SUPPORT_EMAIL. For self-hosted installs, configure this during deploy.

For Bulwark-Black-run instances, the address is support@bulwarkblack.com.

Voice input (Deepgram)

The modal has a microphone button. Click it once to start recording, click again to stop. The audio gets uploaded to the portal's /api/transcribe endpoint, sent to Deepgram's nova-2 model, and the transcribed text drops into the message textarea. You can edit before submitting.

Limits: 20 transcription requests per hour per user, 8MB max audio per request.

Screenshots

Click the paperclip icon to attach files. Up to 5 PNG / JPG / WebP images, 5MB each. Each screenshot shows as a thumbnail in the modal with a remove button.

The screenshots arrive in the recipient's inbox as actual email attachments, not external links — they can be viewed inline without leaving the email client.

The modal itself

The Report a Problem button shows up in the header of every authenticated page (admin and client portals). The button is a small icon that expands into a modal when clicked. The modal:

• Renders via createPortal to document.body so it escapes the page's stacking context (avoids issues where the modal got clipped by header backdrop-filter elements).
• Doesn't persist anything to local storage. If the reporter navigates away mid-draft, the message is lost. Intentional — keeps the modal simple, and most reports are written from scratch each time.
• Submits as multipart/form-data so screenshots upload alongside the message.

What you do when you receive one

1. Read the message + context (which user, which page, what they were doing).
2. Open the attached screenshots if they shed light on the issue.
3. Reproduce the issue using the URL and the account context.
4. Reply to the reporter from your normal inbox — the report email's From address is set to whatever your sender domain is, so the reporter sees the reply come from your brand.

When clients use it

The same button appears in the client portal header. Reports submitted from the client side carry the customer's email and organization context, so when an acme@example.com client reports an issue, you see exactly which Acme account it came from.

This is intentionally not a public support ticket system. There's no thread, no status, no SLA tracking. It's a fast way to relay "something's wrong here" with the context attached.