Admin Configuration Guide

Audience: Privacy/compliance admins configuring and operating the DSR module day-to-day

This is the working reference for building and maintaining workflows, steps, submission forms, email templates, authentication methods, and the Privacy Portal. See Legal & Compliance Guide for the compliance context behind these settings, and Technical Implementation Guide for connecting third-party systems and the API.

Workflows and conflict resolution

A workflow is scoped by request type + data subject category + jurisdiction (+ business entity, if you run Multi-Portal - see below). The workflow editor has three tabs:

• Overview - name, default assignee, request type, subject categories, jurisdictions, and the publish toggle.
  • This tab also has a Triggers accordion, on any workflow - the general mechanism for letting something other than a direct submission start a request into this workflow. Two cases use it today:
    • Opt-In workflows - system-generated, for their internal branching.
    • Custom DSR Trigger Task - any workflow you want an external system to feed via a trigger connection (see Technical Implementation Guide).
  • For the Trigger Task case, add the trigger connection and configure its Rules (JSON) here - a workflow won't accept requests from a Trigger Task connection until it has a matching Trigger entry, even if that connection's workflow_id already points at it.
• Steps - the step builder: add, reorder, clone, and delete the steps that make up this workflow's execution logic (webhook calls, manual tasks, pauses, emails, and more). See Steps below for the full breakdown of step types and configuration.
• Email Templates - the email templates available to this specific workflow's Send Email steps, distinct from the tenant-wide template library under Settings → DSR → Email Templates. Configure subject/body content, localization bundles, and preview here. See Email templates below for tokens and filters.

How a request is matched to a workflow

A workflow only matches a request if all of the following line up:

• Request type - the request's type (Access, Delete, Update, Info Request, File Complaint, Opt Out, Opt In) must be included in the workflow's configured request type(s).
• Data subject category - the subject's category (Customer, Employee, Vendor, etc.) must be included in the workflow's configured subject categories.
• Business entity - if you run Multi-Portal, the request's business entity must be included in the workflow's configured business entities. (If you don't run Multi-Portal, this dimension doesn't apply.)
• Jurisdiction - the request's jurisdiction must fall within the workflow's configured jurisdiction(s).

Request type, subject category, and business entity are exact-match filters - a request either falls within a workflow's configured set for each of these or it doesn't; there's no fallback. Jurisdiction is the one dimension with a fallback precedence, since Relyance resolves the single most specific jurisdiction match among workflows that already satisfy the other three:

1. Exact state + country match
2. Country-only match (no state)
3. Fall back to a workflow scoped to Global

Configure your Global workflow deliberately - it's the catch-all for any jurisdiction you haven't explicitly addressed, for whatever combination of request type/subject category/business entity it's scoped to.

Conflict resolution

You cannot save or publish a workflow whose scope (request type × subject category × jurisdiction × business entity) overlaps another already-published workflow. Attempting to do so surfaces a "DSR Workflow Has Conflicts" dialog listing every workflow it overlaps with (it can list more than one). To resolve:

• Delete or unpublish the conflicting workflow, then re-save, or
• Narrow your new workflow's scope - remove an overlapping jurisdiction, request type, or subject category so the two workflows' match-sets no longer intersect.

This check runs across every combination - one-vs-one, one-vs-many, and many-vs-many overlaps are all caught, not just exact duplicates.

Steps

Add steps from the Steps tab; each new step is appended and auto-expanded. Steps are drag-reorderable, and can be cloned or deleted from the step header. The step-type dropdown is filtered to what's relevant for the workflow's request type - for example, Delete/Update workflows only offer delete-capable step types.

Step types

Common step properties

Every step (except Pause) has a Name and a Run in Parallel toggle, letting independent steps execute concurrently rather than strictly in sequence.

Webhook/integration steps (Data Access Webhook, Data Delete Webhook, Rule Webhook, Third Party Access/Delete) additionally have:

• Connection - select an active, DSR-capable connection from the dropdown (see Connecting a Custom DSR Task below and Technical Implementation Guide for the pre-built catalog). An inline Configure/Edit Connection link jumps to that connection's detail page.
• URL, Request Method (GET/POST/PUT/PATCH/DELETE), Custom Headers, and Body - the actual request this step sends when it runs. This is independent of any reference URL stored on the connection itself.
• Advanced Config - an "Edit JSON" button opening a raw JSON editor bound to the step's rule configuration, for settings not exposed in the structured form (response-path extraction, conditional skip logic, and more). See Technical Implementation Guide for the full reference.
• Redaction Templates - a dedicated modal for viewing and hand-editing saved redaction templates for this step's data source(s), letting you toggle which JSON paths are redacted (or disclosed) by default whenever this step runs. In practice, most redaction templates are created via Test Step rather than built here from scratch - see Step testing below. See Legal & Compliance Guide.

Manual steps carry a task list editor: each task has a title, a rich-text description, a priority, a due interval (in days from step start), and a default assignee. Tasks can be reordered, cloned, and deleted independently of the step itself.

Pause steps offer two modes: Until Manual Intervention (an admin must explicitly resume it) or For a Specified Time (days/hours/minutes/seconds, independently bounded). Pairing an access step with a pause step ahead of a delete step is a common pattern - it gives a reviewer a chance to confirm the deletion before it executes.

Send Email steps let you choose the recipient (data subject, authorized agent, or custom recipients), the send strategy (automatic, or held for manual review/send), and which email template to use. See Email Templates below.

Step testing

Before publishing, use the Test Step action in the step editor to run a synthetic payload through a single step and review the result - including its own scoped audit log of the test run - without affecting a real request. This is the recommended way to validate a new webhook or connection before it goes live.

Building a redaction template from a test run (Access, Delete, Rule Webhook, and Third Party Access steps): the test result view shows the actual data the step returned, grouped by data source, with a redact/disclose toggle on each row - the same interaction used on a real request's Access Report. Toggle the fields that should be redacted or disclosed, then click Create Template to save those choices as this step's redaction template, applied automatically the next time the step runs for a real request. This is generally easier and less error-prone than hand-writing JSON paths in the Redaction Templates modal, since you're working against real returned field names rather than guessing at them.

Create Template is disabled (with a tooltip explaining why) when the test result contains duplicate/ambiguous source names across the returned data - resolve that ambiguity (e.g., by adjusting pathToSourceName/staticSourceName in Advanced Config) before a template can be saved from that run.

Connecting a Custom DSR Task

Custom DSR Task is the generic, webhook-based connector for bringing an internal or otherwise-unsupported system into your DSR workflows without waiting on a pre-built integration. A Connection holds the credentials; the step holds the request details (URL, method, headers, body) - separating the two means rotating a credential doesn't require touching every step that uses it.

Part 1 - create the connection:

1. Navigate to Settings/Configuration → Integrations.
2. Find and select the Custom DSR Task tile.
3. Click Add Connection, confirm or edit the pre-filled name, and click Add.
4. On the connection detail page, configure:
   • Authentication - Custom API Integration (API key/basic auth as JSON), OAuth2 (Client Credentials), or OAuth2 (Authorization Code).
   • DSR Access URL / DSR Delete URL (optional) - reference metadata only; not called at runtime.
   • Name of Target Vendor / Name of Internal Service (optional) - labels for your team.
5. Save. Once authentication succeeds, the connection shows active and becomes selectable from any DSR-capable step.

Part 2 - use it in a workflow:

1. Add a Data Access Webhook step for the access/export side of the request, and a Data Delete Webhook step for the deletion side.
2. On each step, select the connection you created, then configure that step's own URL, Request Method, Custom Headers, and Body.
3. Set Advanced Config for anything not covered by the structured fields - see Technical Implementation Guide.
4. Save the workflow.

You can reuse the same connection across multiple steps and multiple workflows wherever they authenticate against the same system - only use separate connections when access and deletion are handled by different systems or credentials.

A separate connector, Custom DSR Trigger Task, is used to trigger a DSR from an external system rather than fulfill one - see Technical Implementation Guide.

Submission forms

Submission forms define what a data subject (or authorized agent) is asked when they submit a request via the Privacy Portal. Configure them under Settings → Submission Forms. New locales can be machine-translated in one step rather than written by hand - see Machine translation below.

Each field has:

• A name (localizable per-locale) and optional button text.
• A field type: Location, Phone Number, Short Text, Checkboxes, Attachment, Select, or Datepicker.
• A field-to-subject mapping (optional): bind the field to a canonical subject attribute - Subject ID, Email, First/Last Name, Phone Number, Preferences, or (for authorized-agent forms) Authorized Agent Name/Email/Documents.
• A form audience: Data Subject or Authorized Agent - a form can be built for either audience, letting you present a different intake experience (and different required fields, like an authorization document upload) to an agent submitting on someone else's behalf.

Fields are reorderable, cloneable, and deletable.

Checkbox fields: additional information text

Checkbox options can show an optional free-text sub-field beneath them. On each option, set the Additional Information Input Setting:

When either is selected, configure the Additional Information Text Label (defaults to "Additional information," localizable). This label is instructional only - it isn't submitted as part of the DSR; only the subject's typed text is.

On the admin DSR detail view, this text appears beneath the checkbox option in the Custom Fields section, and - if the checkbox is mapped to Subject Preferences - also beneath the corresponding row in the Request Details card. If the subject leaves it blank, no empty value is stored.

This is supported on the Checkboxes field type only, and each option is configured independently - enabling it on one option doesn't affect any other option on the same field. If you edit the label after publishing, the new label appears on the portal for new submissions only - DSRs already submitted keep whatever label was in effect at the time.

Email templates

Configure templates under Settings → DSR → Email Templates, or directly within a workflow's Email Templates tab. Templates support localization bundles (a separate subject + body per locale, default en-US) and a live Preview against a real data subject record. New locales can be machine-translated in one step rather than written by hand - see Machine translation below.

Subject profile tokens

Available in every DSR email template:

For anything not covered above, use the subject object directly: {{ subject.firstName }}, {{ subject.emails }}, {{ subject.type.name }} (subject category), {{ subject.preferences }}, {{ subject.customFields[0].value }}, and arbitrarily deep dot-notation chains ({{ subject.customFields[2].meta.details.file_type }}).

To find a custom field by name rather than by index (safer, since field order can vary), loop and filter by field.name:

{% for field in subject.customFields if field.name == "Loyalty Tier" %}
  {{ field.value }}
{% endfor %}

Three legacy tokens ({{ firstName }}, {{ lastName }}, {{ emailAddress }}) still work for backwards compatibility but shouldn't be used in new templates - use the subjectFirstName/subjectLastName/subjectEmailAddress equivalents instead.

Checkbox / preference data in templates

• Preference-mapped checkboxes are stored on subject.preferences as {name, checked} objects. Use the built-in filters ALL_PREFERENCES, CHECKED_PREFERENCES, and UNCHECKED_PREFERENCES against the subject variable to render a formatted list, or iterate manually with {% for pref in subject.preferences %}. Compact form - just the checked option names as a list:

  {{ subject.preferences | selectattr('checked', 'equalto', true) | map(attribute='name') | list }}

• Unmapped checkbox fields live on subject.customFields, each with a checkboxesAnswer array of {name, checked, additionalText} objects. additionalText is only present on an answer if the subject actually typed something - always guard with {% if answer.additionalText %} before rendering it. Compact form - checked option names for one named field:

  {{ subject.customFields | selectattr('name', 'equalto', 'Field Name') | first | attr('checkboxesAnswer') | selectattr('checked', 'equalto', true) | map(attribute='name') | list }}

• The Additional Information text a subject enters is never available through subject.preferences or the preference filters, even for preference-mapped checkboxes - it's only ever accessible via subject.customFields, matching on answer.name. When iterating subject.customFields generically (mixing field types), guard with selectattr('checkboxesAnswer', 'defined') first, since non-checkbox fields don't have that key. Compact form - additional text for one specific preference-mapped option, flattening every field's checkboxesAnswer array before matching:

  {{ subject.customFields | selectattr('checkboxesAnswer', 'defined') | map(attribute='checkboxesAnswer') | sum(start=[]) | selectattr('name', 'equalto', 'Marketing Emails') | map(attribute='additionalText') | select | first }}

  (| select drops unset/None values; | first returns a single string rather than a one-item list.)

• Both field.name and answer.name are case-sensitive - they must exactly match the Field Name and option label configured in the Submission Form editor, or the filter simply won't match anything (no error is raised).

Filters

Workflow step data tokens

Within a workflow's own email steps, you can additionally reference the response from an earlier step in the same workflow: {{ STEPS.ID.responses.field_name }} for a step with a single synchronous response, or {{ STEPS.ID.responses.response_name.field_name }} for a step that can receive multiple named async payloads (tag each payload with a Response Name on the step). Use the in-editor variable picker to browse available step responses without typing the path by hand, and Test Step to confirm a path resolves before saving.

If a token is misspelled or a referenced field is unavailable, the template simply renders a blank string at that position - it will not error out the send.

Authentication methods

Configure how a data subject proves their identity before accessing their Privacy Portal request, under Settings → DSR → Subject Authentication Methods. Supported methods:

• Email magic-link - a one-time authenticated link sent to the subject's email.
• OAuth - authenticate via an existing identity provider.
• Parameter-based authentication - authenticate via a signed parameter (commonly used for embedded/deep-linked portal flows).

Authentication methods can be scoped per data subject category, and - where Multi-Portal is enabled - per business entity. An authentication method can also be scoped to the Authorized Agent audience specifically, letting an agent authenticate independently of the data subject they're submitting on behalf of - see Authorized agent submissions below.

Authorized agent submissions

A person can submit a request on a data subject's behalf as an authorized agent, provided they upload an authorization document (e.g., a signed power of attorney). To configure this:

1. Under Settings → DSR → Subject Authentication Methods, set up (or confirm) an authentication method scoped to the Authorized Agent audience, so an agent can verify their own identity when accessing the portal rather than needing the data subject's own credentials.
2. Build a submission form with Form Audience set to Authorized Agent, including an Attachment field mapped to Authorized Agent Documents.
3. Configure agent-specific email templates (separate templates can target the email sent to the data subject vs. the one sent to the authorized agent) using the {{ authorizedAgentName }} / {{ authorizedAgentEmail }} tokens.
4. On any Send Email step, choose the appropriate Submission Type/recipient handling for agent-submitted requests.

See Technical Implementation Guide for the equivalent API-driven flow (useful for spreadsheet- or ticketing-system-driven intake instead of the Privacy Portal).

The Privacy Portal

The Privacy Portal is the branded, self-service surface where a data subject submits a request, authenticates, and later downloads their results. Configure branding and behavior under Settings → DSR → Web App:

• Design & Branding - logo, colors, fonts, header/footer/hero images.
• General Settings - portal-wide behavior settings.
• Localizable Content - all subject-facing copy, per locale.

Machine translation

Rather than manually writing out every locale's copy, you can auto-translate content into a new locale via Manage Locales (available on the portal config, submission form, and email template screens):

• Add Locale - add a new locale and machine-translate the source locale's content into it in one step.
• Sync Locales - re-run translation for one or more locales you already have, useful after you've updated the source-locale copy and want dependent locales to catch up.
• Make Default - change which locale is treated as the translation source and fallback.
• Delete Locale - remove a locale.

Both Add and Sync ask you to choose a translation mode:

Translation runs server-side in a single call per surface per locale (rather than field-by-field), and covers:

• Portal - roughly 100 text fields across the portal configuration.
• Submission forms - intro text, field names, upload button text, option names, and option additional-info labels (see Checkbox fields: additional information text) across every form.
• Email templates - the subject and body of every template.

Translation is powered by Google Translate, not a human/professional translation service - treat the output as a strong first draft, especially for anything customer-facing with legal or regulatory language, and have someone fluent in the target locale review it before publishing.

Multi-Portal / multiple business entities

If your organization operates multiple brands or legal entities that each need their own branded intake experience, Relyance supports running multiple, independently configurable Privacy Portals under one tenant - each with its own subdomain prefix and its own enabled/disabled state. When this is configured:

• Workflows, auth methods, and the request list can all be scoped or filtered by business entity.
• The DSR API's businessEntityId field becomes required on request creation (see Technical Implementation Guide).
• Each portal resolves independently based on the subdomain the subject visits, and a portal that's disabled 404s rather than falling back to another one.

Manage your portals under Settings → DSR → Portals.

Managing requests from the list

Once workflows are live, day-to-day work happens from the request list rather than the workflow editor. A request's status tells you where it stands:

From the request detail page, an admin with edit permissions can:

• Assign/reassign - a single-assignee picker on the request's title bar sets who owns working this request. Reassigning fires an audit log entry.
• Extend the deadline - opens a dialog to add a number of days (1-900) to the request's due date. You can optionally notify the data subject and/or (where authorized-agent submissions are enabled) the authorized agent, provided a deadline-extension email template is configured - each notify option only appears if its template exists.
• Cancel the request - requires selecting a Cancel Reason (Excessive, Internal Error, Manually Cancelled by Data Subject, Manually Cancelled by Authorized Agent) and optionally a final message; you can again choose to notify the data subject and/or authorized agent if a cancellation email template exists. A canceled request is terminal - see Legal & Compliance Guide on reopening.
• Publish the Access Report - once an Access request has finished compiling data, it sits ready-to-release until an admin clicks Publish. This is the action that actually makes the Access Report available to the data subject on the Privacy Portal - and it's also the moment the redacted/disclosed state of the report locks in, so review redactions before clicking it. See Legal & Compliance Guide.

Working an individual step

Expanding a step on the request detail page surfaces step-level controls, shown or hidden based on that step's current state:

• Retry Step - appears on any step currently in an Error state (including a timed-out step, which also ends in Error) - re-runs just that step rather than the whole request. This is the per-step counterpart to the list-level bulk Retry action (see Audit Logs, Troubleshooting & Reporting), useful when you want to retry one specific stuck request right after fixing the underlying issue rather than waiting to batch it with others.
• Pause - appears on a step that's actively In Progress, waiting on a third party, or already in a timed pause - lets an admin manually hold a step regardless of whether it hit a configured Pause step. Not available on Send Email steps.
• Resume Step - appears on a paused step (or one awaiting an ad-hoc/manually-triggered email) and continues it from where it left off. On an errored step, this same button relabels itself "Skip Step" - clicking it in that state skips the step entirely rather than resuming it, since there's nothing to "resume" on a step that failed. Use Retry Step instead if you want the step to run again rather than be skipped.

All of these require edit permission on the DSR module, and each action - retry, pause, resume, skip - is captured in the step's audit log entry.

From the list view itself, each row's ⋮ menu offers View and Delete (delete requires edit permission and a confirmation prompt). For filtering, exporting, and the bulk Retry action across many requests at once, see Audit Logs, Troubleshooting & Reporting. Every assignment change, deadline extension, and cancellation is captured in the request's audit log - see Audit Logs, Troubleshooting & Reporting.

The Access Report

When an Access request completes, the data subject receives a consolidated Access Report with four sections:

1. Request Details - name, reference ID, request date, publish date.
2. Table of Contents - hyperlinked to each section of the report.
3. Summary - file count and total size.
4. Data - structured data (JSON/CSV) rendered as readable tables; PDFs and images are embedded inline.

Individual files remain separately downloadable from the report or directly from the Privacy Portal. The report reflects the redacted/disclosed state as of publish time - see Legal & Compliance Guide.

Data subject categories

DSR workflows are scoped in part by Data Subject Category (Customer, Employee, Vendor, Job Applicant, etc.) - the same taxonomy used throughout Relyance's data classification engine. Categories are managed centrally under Settings → Platform Config → Field Customization, not inside the DSR module itself. See your Data Classification documentation for how to add, rename, or retire categories - changes there are reflected immediately in DSR workflow scoping and submission form mapping options.