# Audit Logs, Troubleshooting and Reporting *Audience: Compliance, auditors, admins* This guide covers what's captured in the audit trail (especially for third-party/integration steps), how to view and export it, the dashboard and request-list reporting surfaces, and how to diagnose the most common failure modes. ## The two audit log surfaces Relyance has two distinct, purpose-built audit log views. They're easy to conflate - use this table to find the right one: | Surface | Answers | Where to find it | |---|---|---| | **Request-level audit log** | "What happened on this specific DSR, and when?" | DSR detail page → Audit Log tab | | **Step-testing audit log** | "What happened during my test run of this one step?" | Step editor → Test Step modal | ### Request-level audit log The most important surface for day-to-day operations and compliance evidence. Columns: **Name** (the event, e.g., "DSR Canceled," "New Comment Added," "Access Data Published"), **User** (the person who performed it, or a system/automation label distinguishing workflow-triggered, API-created, or subject-initiated actions), and **Date & Time**. The grid auto-refreshes and rows expand to show full detail. Events you'll see logged here include, non-exhaustively: - **Request lifecycle**: created, started, canceled (with the reason text), deadline extended (old date → new date), published, completed, status changes, assignment changes. - **Step execution**: initiated, success, paused, failed, skipped, timed out, retrying, resumed. - **Third-party/webhook calls**: every webhook request and callback, with the full raw HTTP exchange available for download (see below). - **Comments**: added, updated, deleted - each row expands to show the actual comment text (old vs. new, for edits), plus any attached files. - **Attachments**: manual attachment added/deleted (filename quoted in the message), authorized-agent document uploaded, attachment type rejected. - **Emails**: one "Email Sent" entry per automatic or manually-triggered send. - **Manual tasks**: priority/assignee/due-date/status/tag changes, each with a human-readable "changed from X to Y" message. ### Third-party/integration step audit detail This is the richest and most audit-relevant path. When a webhook step calls a third-party system, Relyance captures the **complete raw HTTP request and response** exchanged with that system - URL, method, headers, body, status code, and cookies - and makes it available for download directly from that step's audit log entry. This is what lets you show an auditor or regulator exactly what was sent to a vendor and exactly what came back, for any given request, at any point after the fact. ## Reporting: the Dashboard and request list ### Dashboard Accessible from the DSR module home or left-nav, the dashboard surfaces four headline metrics - **Requests Received**, **Completed**, **Overdue**, **Average Processing Time** - plus charts breaking down request types, statuses, fulfillment-time trend, data subject category distribution, and a jurisdiction map. ### Request list: filters The request list supports filtering by: request/access type, jurisdiction, data subject category, deadline ("next N days/hours/weeks" or "past deadline"/overdue), request date (canned ranges or a custom range), status, assignee, business entity (where Multi-Portal is configured), and free-text search. Filters compose with AND semantics - a request must match every active filter to appear. ### Exporting The currently filtered request list can be exported as CSV or XLSX - export uses the exact same filter/aggregation logic as what's on screen, so what you've filtered to is what you'll get in the export. ### Bulk actions Currently one bulk action is available from the request list: **Retry**, for re-attempting requests in an Error state. It supports both an explicit multi-select and a "select all matching this filter" mode (useful for retrying every error after fixing an underlying integration issue), and shows a status modal reporting how many were retried vs. skipped. ## Notifications Workflow-failure notifications are configurable under **Settings → Notifications**, with two independent channels - **email** and **in-platform** - each of which defaults to **off**. Both are also subordinate to your organization's master notifications toggle; if that's off, workflow-failure alerts won't fire regardless of the per-channel setting. Turn these on so your team is alerted proactively when a workflow stalls, rather than discovering it when a deadline is already close. ## Comments Add internal notes to a request (or to a specific manual task) from the **Comments** panel on the DSR detail page. Comments require the DSR-annotate permission scope to view or post. Every comment action - add, edit, delete, and attachment changes - is captured in the request-level audit log with a full before/after diff of the comment text. ## Troubleshooting ### A request is stuck / not progressing Check the request-level audit log first - the most recent step event (paused, failed, timed out, waiting on a manual task) tells you exactly where it's stuck. A request in **Waiting On Request** status is blocked behind a prior open request for the same subject and will not proceed until that one resolves. A request in **Awaiting Manual Tasks** is waiting on a human to complete a manual step - check task assignment and due dates. ### Troubleshooting a failed third-party step Open the failed step's audit log entry and download the raw request/response detail - the HTTP status code and response body returned by the target system will almost always tell you what went wrong (expired credentials, changed API endpoint, rate limiting, a field the target system rejected). Cross-check against the connection's authentication configuration under **Settings/Configuration → Integrations** before assuming a Relyance-side issue. ### A workflow won't save / publish You're hitting the conflict-prevention check described in [Admin Configuration Guide](/docs/data-subject-requests/admin-configuration-guide/#conflict-resolution). The dialog names every workflow it conflicts with - either narrow your new workflow's scope or retire the conflicting one. ### Emails aren't sending, or aren't reaching the right recipient Confirm the Send Email step's recipient type (data subject vs. authorized agent vs. custom recipients) and send strategy (automatic vs. held for manual review) are set as expected. If a token in the template is misspelled, the email still sends - the token just renders blank - so a blank field in a sent email is a templating issue, not a delivery failure; check the audit log's Email Sent entry for the exact rendered subject/body. ### A completed or canceled request needs more work Closed requests cannot be reopened - create a new DSR to continue.