Order matters
If a request comes in while Notification Emails is blank, the request is created, the requester gets their acknowledgment, but your team gets nothing. The audit shows email.notification_skipped with reason no_recipients_configured. There's no automatic catch-up; you'll miss the request until you check the dashboard.
Open Settings
Open Shield > Settings from the sidebar. The page is one form with five inputs. There is no list of rows or multi-row management because Shield uses exactly one settings row per company.
Notification Emails
One or more comma-separated email addresses. These receive a new request alert as soon as someone submits, deadline warnings at 7 and 3 days remaining, and a one-shot OVERDUE alert the day a request crosses its deadline. Use a distribution list or shared mailbox so vacation does not break compliance. A single personal mailbox is a single point of failure for a regulatory obligation.
Support Email
The address requesters see on the acknowledgment email footer, the rejection email footer, and the public status page. This is the visible "contact us with questions" address for the privacy workflow. It does NOT have to be the same as Notification Emails; this one is requester-facing, Notification Emails is internal-only.
Default Deadline Days
The fallback used only when applicable law cannot be auto-detected (the requester left country blank, or chose a country not in our jurisdiction map). When law is detected, the per-jurisdiction window takes over: 30 days for GDPR, PIPEDA, Quebec Law 25; 45 days for CCPA, VCDPA, CPA, CTDPA. Default value here is 30.
Auto Purge Days
How long closed (Complete or Rejected) requests stay in the system before being hard-deleted. Default is 90, which lines up with typical regulatory "minimum retention proves we handled it; longer than 90 days is over-retention" thinking. The purge job runs daily at 09:00 UTC and removes the request, all its audit entries, and any identity document in S3.
Set to 0 to disable auto-purge entirely. Note: the S3 lifecycle on uploads/request/ still deletes identity documents at 365 days as a safety net, regardless of this setting. If your legal team requires longer document retention, that's a deployment-level conversation.
Save
Click Save. The settings row writes to DynamoDB shield.settings keyed on your company_id. Future requests use these values immediately.
Where Cloudflare Turnstile lives
Bot protection is deployment-level, not per-company. Turnstile is configured in web.config (Shield.Turnstile.Enabled and Shield.Turnstile.SiteKey) plus the intake Lambda's environment (TURNSTILE_ENABLED and TURNSTILE_SECRET_KEY). The Settings page does not surface these because they apply to all companies on the deployment, not just yours.
If you're rolling Shield out to multiple companies on the same deployment, each company configures its own Settings row independently. The deployment-level config (Turnstile, default templates, S3 lifecycle) is shared.
Troubleshooting
I saved but the notification still does not fire
Settings has a `last_deadline_check` timestamp and a `last_purge_run` timestamp that get updated by the scheduled jobs. Check the audit trail of a freshly submitted request. If it shows email.notification_sent with recipient_count: 1 (or higher), notifications are working. If it shows email.notification_skipped with reason no_recipients_configured, Settings did not save correctly; reload and verify the value persisted.
AutoPurgeDays is set but old requests are not being purged
The purge job only runs daily at 09:00 UTC. If you just set it 30 minutes ago, the next run is tomorrow. To force a run, an admin can execute TagPipes.Console.exe -c SHIELD.PURGE.OLD -x <company-id> from the console.