# Workflows: Quickstart Guide (/docs/dsr-automation/quickstarts/workflows-quickstart) ## Introduction and Purpose [#introduction-and-purpose] **Workflows** are the engine for automating your privacy program. They allow you to build, manage, and execute the precise steps needed to handle Data Subject Rights (DSR) requests in a compliant, scalable, and transparent way. This guide explains what makes this system special and provides a step-by-step walkthrough for creating your first workflow. The core of the system is built on a simple but powerful idea: workflows are designed to be clear, single-purpose, and easy to manage, which reduces errors and makes it easy to adapt to new regulations. ### Key Principles [#key-principles] - **Workflows are unique to a combination of:** - **Data Action:** The specific right being exercised (e.g., Access, Erasure). - **Data Subject Type:** The category of person making the request (e.g., Customer, Employee). - **Single-purpose, targeted workflows** are strongly preferred over attempting to build one large, complex workflow with many internal rules. - **Duplicating and editing existing workflows** is the fastest and most reliable way to support new regions or subject types. ### What Makes Workflows Special? [#what-makes-workflows-special] - A streamlined, 5-step wizard to guide you through DSR configuration. - A simple **Identifiers** page that alerts you when certain identifiers are missing for a given data system and provides a simple way to fix the issues without leaving the configuration screen. - The ability to **duplicate workflows** and manage them independently — providing flexibility to build and maintain workflows in a distributed team setting, to help you scale your compliance effortlessly. ## Core Concepts and Key Terms [#core-concepts-and-key-terms] | Term | Definition | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workflow | An automated process for fulfilling a single data action for a specific subject type. | | Data Action | The type of compliance request, such as "Access My Data" or "Delete My Data." Supported actions include: Access, Erasure, Rectification, Restriction, Opt Out of Sale, Opt Out of Tracking, Communication Opt-In/Out, and more. | | Data Subject Type | The classification of the individual, like Customer, Employee, or Authorized Agent. | | Preflight Check | An automated verification step that runs before a request is fulfilled, such as identity verification. | | Enrichment | The process of gathering additional identifiers for a data subject to ensure systems can find their data accurately. | | Integration | A connected data system, application, or database where subject data is stored (e.g., Salesforce, Stripe, AWS S3). | | Datapoint | A specific data object or resource within an integration (e.g., a customer profile, a support ticket, or a payment record). | | Deletion Dependency | A rule that holds an integration's erasure until other integrations have finished deleting, so for example a downstream system cannot re-ingest data that an upstream system has not cleared yet. Defaults are set on the integration, and erasure workflows can override them. | ## Quickstart: Step-by-Step [#quickstart-step-by-step] ### Prerequisites [#prerequisites] - **Admin access** to the Transcend platform. - The **Workflows UI** must be enabled for your account. - You have a list of systems where you'd like to process workflow requests (**Integrations**). - You have a clear understanding of your organization's compliance obligations for each subject type you support. ### Step 1: Create a New Workflow [#step-1-create-a-new-workflow] Navigate to **Privacy Requests > Workflows** in your Admin Dashboard. If no workflows exist yet, you will see a banner noting that DSRs submitted through the Privacy Center will default to legacy DSR Automation behavior until at least one workflow is published and visible. Click the **"New Workflow"** button in the top right. In the **Create Workflow** modal, fill in: 1. **Workflow title** — This is what your workflow will be called in the Admin Dashboard and in the Privacy Center where users will make requests (e.g., "EU Customer Erasure"). 2. **Internal name** — Only shown in the Admin Dashboard to help you tell workflows apart. Does not change the name shown to users. 3. **Data action** — Select the type of request this workflow will handle. Available actions include: Access, Erasure, Rectification, Restriction, Opt Out of Sale, Opt Out of Tracking, Opt In/Out of Automated Decision-Making, Communication Opt-In/Out, Sensitive Information Opt-In/Out, Custom Opt-In/Out, Place on Legal Hold, Remove from Legal Hold, Business Purpose, and more. 4. **Subject** — Select the data subject for whom this workflow will handle requests. Click **Create** to proceed to the 5-step configuration wizard. ### Step 2: Configure Workflow Details [#step-2-configure-workflow-details] You are now in the **Workflow Details** step (Step 1 of 5 in the wizard). Fill in the **Privacy Center Workflow Descriptors**: 1. **Workflow title** — Pre-filled from the previous step. This appears in the Admin Dashboard and Privacy Center. 2. **Internal name** — Admin-only label to distinguish workflows. 3. **Subtitle** _(required)_ — Appears within the Data Action button of the Privacy Center where users make their requests. 4. **Description** _(required)_ — Gives additional information related to the Data Action after authentication is completed. Configure **Request Settings**: 1. **Data subjects** — Select the data subject type(s) this workflow applies to (e.g., Customer, Former Employee). If you don't see the type you need, you can create a new one. 2. **Show in Privacy Center** — Toggle on to make this workflow visible in your Privacy Center so users can submit requests. Workflows hidden from the Privacy Center can still receive requests via API. Note that workflows will not show in the Privacy Center until you have also enabled "Show the Workflows V2 experience on the Privacy Center?" from [Privacy Center → General Settings](https://app.transcend.io/privacy-center/general-settings) 3. **Collect data subjects' regions** — Choose between: - **"Do not collect region"** — Use this if you apply the same workflow to all regions globally. - **"Collect in form"** — Requesters self-identify their region when submitting a request. 4. **Expiry Time** — Set the maximum number of calendar days that a request must be fulfilled (default: 30). 5. **Advanced Settings** — Optionally configure custom field selection to allow customers to select custom fields when processing these requests. 1. **Accept legacy API submissions** — When enabled, matching calls to `POST /v1/data-subject-request` (same data action and data subject) are routed to this workflow instead of the legacy path. Only one non-draft workflow per action and subject may have this enabled. [See Submit requests via API](#submit-requests-via-api). Click **Save and continue**. ### Step 3: Add or Remove Integrations [#step-3-add-or-remove-integrations] You are now on the **Integrations** step (Step 2 of 5 in the wizard). This step shows all data systems (integrations) that support the data action selected for this workflow. - The **Selected** tab shows integrations already included in this workflow (added automatically if they support the data action). - The **Not Selected** tab shows available integrations you can add. To manage integrations: 1. Review the integrations automatically added. By default, all integrations that support the given data action are selected and enabled. 2. If you'd like to connect a new integration, click **"Connect new integration"** and follow the setup steps. 3. Use the **"Refresh list"** button if an integration is not appearing. 4. Deselect or remove any integrations that are not needed for this workflow. #### Configure deletion dependencies (erasure workflows only) [#configure-deletion-dependencies-erasure-workflows-only] For **Erasure** workflows, the integrations table includes a **Deletion dependencies** column. Deletion dependencies control the order integrations run during an erasure request: an integration waits until every integration it depends on has finished deleting. - **Global defaults** are configured on each integration under [**Infrastructure → Integrations**](https://app.transcend.io/infrastructure/integrations) → your integration → **DSR Automation**. These apply to every erasure workflow, and to legacy DSR Automation requests. - **Workflow overrides** let a single erasure workflow use a different dependency list for an integration, without changing the integration's global setting or affecting any other workflow. To review or override deletion dependencies for this workflow: 1. In the **Deletion dependencies** column, click **Configure deletion dependencies** on the integration you want to configure. 2. In the drawer, review the integrations under **Currently selected**. While the workflow is inheriting global defaults, this list is read-only and reflects the integration-level configuration. 3. Turn on **Override global defaults?** to choose a different list for this workflow only. 4. Use the **Not selected** list to add integrations, and clear the checkbox on any you no longer need. Only integrations that are already part of this workflow can be selected. 5. Click **Apply** to save the override, or **Cancel** to discard your changes. ![Image of the workflow dependency drawer open](/images/sanity/app.transcend.io_privacy-requests_workflows_f7fb7e14-f8cc-4450-a58c-3f03d8b4b493_configuration_pagesize-10-step-integrations-transcend-standard-size-1.png) **Reset to global defaults** If a workflow has an override and you want it to follow the integration-level defaults again, open **Configure deletion dependencies** for that integration, turn off **Override global defaults?**, and click **Apply**. The workflow-specific list is removed and the workflow inherits the global deletion dependencies again. **Override with no dependencies** If you turn on **Override global defaults?** and leave nothing selected, this workflow runs that integration with no deletion dependencies, even when the integration has global dependencies configured. Use this when a specific workflow should delete from that system right away instead of waiting on other integrations. > **Note:** The **Deletion dependencies** column appears only on Erasure workflows, and only for integrations that are selected for the workflow. Click **Continue to Identifiers**. ### Step 4: Configure Identifiers & Enrichment [#step-4-configure-identifiers--enrichment] You are now on the **Identifiers** step (Step 3 of 5 in the wizard). This step has two sections: **User Input Identifiers** Select which identifiers the data subject must provide when submitting a DSR (e.g., email, phone). These are used to locate the user's data and may be sent directly to integrations or routed through enrichers. **Workflow Identifiers** A table of all identifiers needed across your connected systems, showing: - **Active** toggle — Enable or disable each identifier for this workflow. - **Identifier Needed** — The identifier type required by one or more integrations (e.g., `email`, `phone`, `coreldentifier`). - **Identifier Source** — Shows how the identifier will be resolved. If no enricher is configured, you will see a warning with links to "Add an enricher" or "add a user input identifier." **Workflow Enrichers** A table of all enrichers connected to this workflow. Enrichers resolve identifiers automatically before a request is processed. - Click **"Add enricher to workflow"** to connect an enricher that can resolve a missing identifier. - You can add both **identity enrichers** (to look up additional identifiers) and **verification enrichers** (to verify the identity of the requester before processing). - Preflight checks such as Government ID verification, phone number verification, and email verification can also be configured here. Fix any flagged identifier issues before proceeding to ensure complete identity resolution and request fulfillment coverage. Click **Continue to Datapoint Actions**. ### Step 5: Configure Datapoint Actions [#step-5-configure-datapoint-actions] You are now on the **Datapoint Actions** step (Step 4 of 5 in the wizard). This step shows all datapoints affected by this workflow across your connected integrations. For each datapoint you can see: - **Datapoint** — The name of the specific data object (e.g., "Custom Datapoint", "Global Profile"). - **Description** — A description of what data is stored in this datapoint. - **Data System** — The integration that owns this datapoint. - **Owners** — Assign an owner (by name or email) responsible for this datapoint. - **Teams** — Assign a team responsible for handling this datapoint. Click on any datapoint row to configure the specific action that should be taken for that datapoint in this workflow (e.g., delete, anonymize, export, redact). Click **Continue to Summary**. ### Step 6: Review, Test, and Publish [#step-6-review-test-and-publish] You are now on the **Summary** step (Step 5 of 5 in the wizard). Review all your configuration in one place: - **Workflow Details** — Title, data action, data subjects, user-provided identifiers, Privacy Center visibility. - **Integrations** — All connected data systems included in this workflow. - **Preflight Checks** — Any configured preflight verification steps. - **Identifiers** — The full list of identifiers and which systems they map to. Each section has a pencil icon to jump back and edit that specific step. **To test before publishing:** Click **"Run Test Request"** to submit a test request using sample data. This simulates a real request and helps verify that the workflow is correctly configured. > **Note:** To use "Review & Publish," the **"Show in Privacy Center"** toggle must be enabled in Workflow Details, or you can publish the workflow as hidden. Once satisfied, click **"Review & Publish"** to publish the workflow. Published workflows are live and will be used to process real requests. ### Managing Workflows from the List View [#managing-workflows-from-the-list-view] From the **Privacy Requests > Workflows** list, each workflow row shows: - **Title** — The workflow name. - **Action** — The data action type. - **Data Subjects** — The subject types covered. - **Regions** — The region collection setting. Hover over any row to reveal the **⋮ menu**, which provides: - **View Requests** — See all DSR requests that have been routed through this workflow. - **Duplicate** — Clone this workflow to create a variation (e.g., clone "EU Customer Erasure" to create "California Customer Erasure" and update the region setting). - **Delete** — Permanently remove the workflow. > **Important:** If no workflows are currently visible in the Privacy Center, DSRs submitted through the Privacy Center will default to the legacy DSR Automation behavior. ## Submit requests via API [#submit-requests-via-api] Workflows can receive requests from the Privacy Center or via API. #### Preferred: bulk API [#preferred-bulk-api] When you are submitting multiple requests, or you want the workflows-native request shape, use [`POST /v1/data-subject-request-bulk`](/docs/api-reference/data-subject-request/post-v1-data-subject-request-bulk). Each item in the `input` array requires: 1. `workflowConfigId` — the UUID of the published (non-draft) workflow config. Find it in the Admin Dashboard under **Privacy Requests** → **Workflows**. 2. `attestedAuthContext` — at minimum `coreIdentifier`; include `email` when not in silent mode. Do not pass `type` or `subjectType` on bulk items — the API derives those from the workflow config. #### Singular API (workflows v2 routing) [#singular-api-workflows-v2-routing] Organizations on workflows v2 can also submit through [`POST /v1/data-subject-request`](/docs/api-reference/data-subject-request/post-v1-data-subject-request). While this endpoint will be deprecated, using it with workflows v2 helps reduce the number of changes while onboarding. Keep the existing request shape: `type`, `subjectType`, and identity fields remain required. Routing works as follows: 1. **Explicit id** — When you pass optional `workflowConfigId`, the request is submitted through that non-draft workflow. 2. **Flagged lookup** — When you omit `workflowConfigId`, Transcend looks for a non-draft workflow with **Accept legacy API submissions** enabled (`allowLegacyApiSubmission=true`) that matches the request `type` and `subjectType`. When found, the request is routed to that workflow. 3. **Legacy fallback** — Otherwise (organization not on workflows v2, or no matching flagged workflow), the request uses the legacy submission path unchanged. When the request is routed through workflows v2, the response includes an additive `workflowConfigId` so you can verify which config was used. **Enabling Flagged Lookup** To enable flagged lookup for a workflow: 1. Open the workflow in **Privacy Requests** → **Workflows**. 2. In **Workflow Details**, turn on **Accept legacy API submissions**. 3. Publish the workflow (only non-draft workflows participate in lookup). Only one non-draft workflow per data action and data subject may have **Accept legacy API submissions** enabled. ## Best Practices & Troubleshooting [#best-practices--troubleshooting] ### Compliance Management [#compliance-management] - **Design for simplicity:** Create one workflow for each unique combination of action and subject type. - **Duplicating workflows is your friend:** Use the Duplicate option to rapidly expand your compliance coverage to new subject types. Avoid building from scratch every time. - **Rely on built-in logic:** Trust the automatic subject-based exposure in the Privacy Center. Do not try to create workarounds with complex internal logic. ### Enrichment, Skipping, and Error Flagging [#enrichment-skipping-and-error-flagging] The system is designed to prevent silent failures. Any enrichment steps that are skipped or cannot be run will be flagged as an issue in the Identifiers step for you to resolve before publishing. ### Debugging and Issues [#debugging-and-issues] If a workflow isn't working as expected, check: 1. Its **Privacy Center visibility** setting (Show in Privacy Center toggle). 2. Any **unresolved identifier issues** flagged in the Identifiers step. 3. That the correct **Data Subject type** is assigned. ## Frequently Asked Questions [#frequently-asked-questions] **Q: Can I create one workflow that handles multiple regions using conditional logic?** A: No. Each workflow is scoped to a single data action and subject type. The region is handled via the "Collect in form" setting where requesters self-identify. To support different behavior per region, duplicate an existing workflow and adjust the settings. **Q: How do I control which workflows my users see in the Privacy Center?** A: This is controlled by the "Show in Privacy Center" toggle in the Workflow Details step. Only workflows with this toggle enabled will be visible to users. **Q: Can I edit a live (published) workflow?** A: Yes. Changes are saved as a draft and do not affect active requests until you explicitly publish the new version. **Q: How do I support a new subject type?** A: Use the **Duplicate** option on an existing workflow. In the new workflow, update the Data Subject type and any other settings that differ. **Q: Can two erasure workflows use different deletion dependency orderings for the same integration?** A: Yes. Set the global defaults on the integration, then open each erasure workflow's **Integrations** step and override the dependencies for that workflow. Workflows without an override continue to use the global defaults. **Q: Where do I set deletion dependencies if I am not using Workflows?** A: On each integration, under **Infrastructure → Integrations** → your integration → **DSR Automation**. Legacy DSR Automation requests always use these global settings. ## Summary and Next Steps [#summary-and-next-steps] - Build simple, single-purpose workflows and **duplicate** them to create variations for different subject types. - Use the built-in **identifier and enricher tooling** at every step to ensure complete coverage. - **Test your workflows** before publishing to confirm they process requests correctly. - Adapt quickly and safely — workflow changes are saved as drafts and don't impact live requests until you publish them. For more detailed information or personalized assistance, contact your Transcend Customer Success representative.