Overview
Every Shield request flows through a deliberate four-status workflow: New -> Acknowledged -> In Progress -> Complete (or Rejected). Closure is the only point where the system automatically emails the requester, and closure-with-rejection requires a written reason that ships in the email and the audit. Everything else (notes, identity verification, deadline warnings, audit export) sits around that backbone.
Privacy work happens almost entirely in Shield > Requests. New requests land from intake forms, you triage and verify, you process internally, and you close the loop with the requester. Every action is timestamped and attributed in the audit trail. When legal or a regulator asks what happened, the answer is already written.
Open a request
Click any reference number in Shield > Requests. The hero card shows the current status pill (color-coded), days remaining or days overdue, request type, and the auto-detected applicable privacy law. Below that, you see the full requester profile, the original request text, the optional identity document, and the audit trail.
Acknowledge the request
Click Acknowledge in the top-right action area. This records that your team has seen the request and saves acknowledged_at on the record. The audit shows a status.changed entry from New to Acknowledged with your name and the timestamp. Some privacy operations use acknowledgment as a formal signal to the requester that the clock has started; others treat it as internal only. Either way, it's the first deliberate step out of New.
Start work
Click Start Work when you begin actively processing. Use the Add Note panel to document your investigation in real time: what systems you searched, who you coordinated with, what you found. Notes are part of the audit trail and visible to anyone with access to the request. They are internal-only and never sent to the requester.
The rule of thumb: if you would want context on this request six months from now, write a note. The cost of writing notes is low. The cost of defending an unwritten decision to legal is high.
Verify identity (when applicable)
If the requester uploaded an identity document, the Verification row in the requester panel shows a grey Not verified pill next to a Download Document link. After visually reviewing the document, click Mark Verified and confirm the attestation modal. Your name and timestamp get recorded into the audit as identity.verified. If on second review you realize the document is insufficient, click Revoke; the audit entry preserves the prior verifier's name and the reason for revocation. The full Verify Identity guide has more detail.
Complete the request
When you've fulfilled the request (delivered the data, confirmed the deletion, processed the opt-out), click Complete. The status flips, completed_at is set, and a green Privacy Request Completed email is automatically queued to the requester. The email includes the reference number, request type, completion date, and a deep link to the requester status page where they can re-check the status later.
The email goes through the system email queue with three automatic retries (2 min then 10 min backoff) if SES has a transient issue. Closure failures get logged as email.closure_failed in the audit with a reason, so you can spot delivery issues.
Reject with a written reason
If you must reject (out of scope, cannot verify identity, fraudulent request, etc.), click Reject. A modal appears requiring a written reason. Empty reasons are blocked both client-side and server-side. The reason is saved on the request, recorded in the audit, and rendered in the rejection email so the requester knows exactly why and what they can do next.
Write the reason as you would explain it to the requester. The reason text ships verbatim into the email, with no further editing. Example: "Unable to verify identity from the document provided. Please resubmit with a clearer government-issued ID." Generic reasons like "Out of scope" without context invite regulator scrutiny if the requester escalates.
Monitor deadlines
Deadlines are calculated automatically based on the auto-detected applicable law (30 days for GDPR/PIPEDA/Quebec Law 25, 45 days for CCPA and the US state laws). Email warnings to your notification_emails fire at 7 and 3 days remaining. An OVERDUE alert with a red header fires once the day a request goes past its deadline.
The overdue alert is one-shot per request, dedup-ed on the false-to-true transition of the overdue flag. You won't get hammered with daily reminders for the same lapsed request; you'll get one urgent ping and then a visual reminder on the Detail page. Resolve it the day you see it.
Audit trail and CSV export
Every action on a request writes to an immutable audit table: submissions, status changes, notes, document accesses, identity verifications, email queue events, exports. Click Export CSV in the Audit Trail panel header to download the entire trail as RFC 4180 CSV for compliance hand-off. The export itself is logged so the trail records who pulled the evidence packet. See the Export Audit Trail guide for the full breakdown.
Auto-purge for retention
Closed requests (Complete or Rejected) are hard-deleted after the company-level AutoPurgeDays setting (default 90). The purge runs daily at 09:00 UTC and removes the request, all of its audit entries, and any identity document in S3. This is your data-minimization compliance: PII does not linger past the retention window. Set AutoPurgeDays=0 in Settings to disable. The S3 lifecycle on identity documents acts as a safety net at 365 days even if the purge job is misconfigured.
The audit trail can be exported anytime via the CSV link in the panel header; export before a request is auto-purged if you want a long-term archive. Notification emails go to whoever is listed under Notification Emails in Shield Settings, not the form's support email. Use a distribution list, not a personal mailbox, so vacation does not break compliance.
Troubleshooting
Closure email did not arrive
Open the audit trail. If you see email.closure_queued, the email made it into the system queue and the queue processor will send it (3 retries with backoff). If you see email.closure_failed, the audit details include the reason. Common cause: the closure template file is missing or the rendered token has a typo. The Lambda side and the web app side render closure emails separately; the web app renders Complete and Reject from App_Data/shield/closure_*.html.
Reject button does not let me submit
The reason textarea is empty. The modal shows an inline error and the server-side guard also returns 400. Enter a reason and resubmit.
Deadline shows the wrong number of days
The deadline is calculated at submission time from the applicable-law detection (country + state). If it looks wrong, check the requester's submitted country and state. If the country is missing, the system falls back to the company-level Default Deadline Days in Settings. You cannot manually edit the deadline; it's a calculated field tied to legal obligations.
Overdue alert did not fire
The alert fires only once on the false-to-true transition of is_overdue. If you backdated the deadline or the daily scheduler skipped the run, the transition may not have occurred. Run TagPipes.Console.exe -c SHIELD.DEADLINE.CHECK -x <company-id> manually to force a check. Also confirm Notification Emails is populated in Settings, since the alert routes there.