Automations

Automations allow you to create workflows that programmatically define how each phase of a Privacy Request is processed. Workflows can evaluate properties such as requester information and data returned by your integrations to determine how requests are processed within your organization. Super Admins and Request Admins can view and interact with Automations.

Common use cases include processing customer and employee requests against different integrations, automatically denying requests based on data subject properties, and conditionally processing deletion based on data retrieved from a primary system of record.

Key Concepts

Before building an automation, it is important to understand the following concepts.

Workflow Phases

The primary trigger for a workflow automation is when a Privacy Request enters one of four phases.

Initialization

The Initialization phase runs before any processing begins, giving you the ability to introduce additional checks and logic at the moment a request is received. This phase is triggered as soon as a Privacy Request is submitted.

Unlike other workflow phases, the Initialization phase replaces the standard pre-processing steps — requests that enter this phase bypass the Active: Wizard, Active: Pending Verification, and Active: Extracting Identifiers states, proceeding directly to Active: Extracting Personal Data when the workflow completes.

Unsupported Intake Sources

The Initialization phase only applies to requests submitted via API, Intake Form, and Request Queue. Requests submitted via Email or Phone bypass this phase and continue to follow the standard Wizard workflow.

Use this phase to:

• Route or validate requests based on how they were submitted (API, Intake Form, or Request Queue).
• Control whether an identity verification email is sent and define what happens next based on the outcome.
• Send a confirmation email to the requester acknowledging receipt of their request.
• Automatically extract secondary identifiers before processing begins.

Extracting Personal Data

All Privacy Request types go through this workflow phase. In this state, API integrations begin querying for Data Subject PII.

Request Type	Behavior
Access, Access Categories, Rectification, Data Portability	All API Integrations query for PII and Direct Contact Integrations send emails to their respective processors.
Deletion, Pause Processing	All API Integrations (except Whole-Record Deletion Integrations) query for PII. Direct Contact Integrations do not send emails in this state.

Pending Action

All Privacy Request types go through this workflow phase. This state allows Privacy Managers to review retrieved data and determine what results to send to the Data Subject or what data to delete. Requests exit this state after a Privacy Manager selects the Process Request button.

Request Type	Behavior
Access, Access Categories, Rectification, Data Portability	Sends the final notification to the Data Subject and moves to closed.
Deletion, Pause Processing	Moves to the Pending Delete state.

Pending Delete

Only Deletion and Pause Processing requests enter this workflow phase. In this state, configured API Integrations execute deletion and Direct Contact Integrations send emails to their respective processors. Once complete, the Data Subject is notified and the request moves to closed.

Understanding The Privacy Request Lifecycle

Before creating workflows, it is critical to understand the Privacy Request Lifecycle in DataGrail. Please review the Request Lifecycle Overview before creating your first workflow automation.

Nodes, Conditions, & Actions

Workflow automations are composed of Nodes, Conditions, and Actions which can be used to build complex logic for processing Privacy Requests.

Term	Definition
Node	A building block in a workflow that represents either a condition or an action, connected to other nodes to define the flow of logic or tasks.
Condition	A node containing a logical statement that evaluates to true or false, enabling branching decisions within a workflow (e.g., if X, do Y; otherwise, do Z).
Action	A node where a specific task is executed, such as sending an email or assigning a request to a user.

Creating a Workflow

To create an Automated Request Manager Workflow, navigate to Automations in the left-hand sidebar.

Choosing The Workflow Phase

The trigger for any workflow is when a Privacy Request enters one of the four valid Workflow Phases. Choose the earliest workflow phase possible to ensure efficiency.

Goal	Recommended Phase
Control verification, confirmation emails, or identifier extraction at intake	Initialization
Route requests differently based on intake method (API vs. Intake Form)	Initialization
Conditionally trigger integrations for Deletion or Pause Processing requests only	Pending Delete
Conditionally trigger integrations for all request types	Extracting Personal Data
Deny or assign a request to a user	Extracting Personal Data

Extracting Personal Data Workflows Influence Deletion Requests

All Privacy Request types go through the Extracting Personal Data workflow phase. If you exclude an integration in this phase, it will also be excluded on a deletion request in the Pending Delete state.

Building The Workflow

To create a new workflow, select Create Workflow, and you will be prompted to enter three required fields: Workflow Name, Description, and Workflow Phase.

Use the "+" button to build out your workflow logic with supported Conditions and Actions.

Conditions

Conditions allow your workflow to make decisions by evaluating a property or data retrieved by an integration. To create a condition node, select Add a Condition and choose which condition to start with.

Evaluating Multiple Values: Conditions support combining multiple values and properties using logical operators.

Action	Logic	Result
Select Add Value	OR	Condition is true if any value matches
Select Add Another Condition	AND	Condition is true only if all properties match

Branching: Once a condition is applied, the workflow splits into a true branch and a false branch. Branches can be layered to create complex logic.

All new branches generated in the Extracting Personal Data phase will automatically have the "Then process all other integrations" and "Complete workflow" nodes. See the Process Integrations Action for more information.

Example Condition

In this example, the condition reads: Policy is CPRA AND (Privacy Right is Access OR Deletion) AND (Data Subject Relationship is Employee OR Former Employee). All three outermost conditions must evaluate to TRUE for the workflow to take the If true branch.

Supported Conditions

The following conditions are available for use in your workflows. Some conditions are only available in specific phases or after certain actions.

If Request Source Is

Allows logic based on the intake method used to submit the Privacy Request.

Available values:

• API
• Intake Form
• Request Queue

Email and Phone Not Supported

Email and Phone intake sources are not supported in the Initialization phase and are not available as condition values. Requests submitted via Email or Phone bypass this phase entirely.

Use Cases:

• Skipping identity verification for requests submitted via API, where the requester's identity has already been confirmed by your platform.
• Requiring verification only for Intake Form submissions.

Request Policy

Allows logic based on the Privacy Request Policy associated with a Privacy Request. All available Privacy Request Policies in your account are able to be evaluated.

Use Cases:

• Denying a request based on a particular Data Subject location.
• Processing a different set of integrations for certain countries/states.

Privacy Right

Allows logic based on the Privacy Right being exercised. All DataGrail Privacy Rights are available for evaluation, except Opt Outs:

• Access
• Deletion
• Object to Processing
• Access Categories
• Rectification
• Data Portability
• Third Party Disclosure

Use Cases:

• Processing a different set of integrations for different request types.

Custom Question Responses

If you have Custom Questions configured in the Privacy Request Center, the responses can be used to build logic in workflow automations.

Each custom question you have configured will appear as a separate condition option in the Add a Condition menu. If you have policy-specific questions, the name of the policy will be listed next to the question.

Important Notes:

• Only dropdown questions (single or multi select) are supported in Conditions.
• Select Add Value to consider multiple dropdown answers in the same condition with OR logic. To utilize AND logic, create an additional condition for the same question.
• If a Custom Question Option or Custom Question is removed from the Privacy Request Center, your workflow will not be impacted. However, any conditions utilizing these options or questions will evaluate to FALSE.

Use Cases:

• Using questions specific to your organization (e.g. products utilized, role, etc.) to determine how Privacy Requests are processed in DataGrail.

Data Subject Relationship

Allows logic based on the Data Subject Relationship entered for the request.

Use Cases:

• Processing a different set of integrations for customers vs. employees.

If Data is Found

Only available in the Extracting Personal Data and Pending Delete phases after a Process Integrations action.

This condition evaluates to TRUE if any of the selected integrations identify data in the preceding Process Integrations action.

Important Notes:

• On a Deletion or Pause Processing request, Direct Contact and Whole-Record Deletion Integrations do not retrieve data. If these integration types are used in an If Data is Found condition on a Extracting Personal Data workflow, they will never retrieve data.

Use Cases:

• Using a primary system of record to determine what integrations should be processed for deletion.

Time Bound Trigger

Only available in the Extracting Personal Data and Pending Delete phases after a Process Integrations action.

To add a Time Bound Trigger select the ellipses (...) on the preceding Process Integrations node and select Add Time Rule.

This condition allows you to skip any unfinished integrations in the preceding Process Integrations node, if they do not complete within a defined amount of days from their initial execution. If the integrations complete before then, the workflow will move past this condition.

Use Cases:

• Skipping a Direct Contact Integration if the processor does not reply quickly.
• Automatically skipping integrations that consistently encounter an error with a third-party API.

Actions

Actions allow your workflow to execute a task. To create an action node, select Add an Action and choose the desired action.

Supported Actions

The following actions are available for use in your workflows. Some actions are only available in specific phases or as termination points.

Then Verify Identity

This action sends an identity verification email to the Data Subject. When added, the workflow automatically creates a true and false branch based on the outcome of verification:

Branch	Behavior
True (verified)	Proceeds to the next step. You may add one additional action before Then move request to next phase.
False (not verified)	Denies the request. The Data Subject receives the Privacy Request Denied email.

While verification is pending, the request remains in Active: Initializing. It does not enter Active: Pending Verification.

The Data Subject receives the Email Verification email template.

Intake Form Requests Cannot Bypass Verification

If your workflow includes an If Request Source Is condition targeting Intake Form, the true branch must use Then Verify Identity. Intake Form requests cannot bypass verification.

Use Cases:

• Sending an identity verification email before a request enters processing.
• Skipping verification for API requests while requiring it for Intake Form submissions.

Then Send Confirmation Email

This action sends a confirmation email to the Data Subject acknowledging that their Privacy Request has been received and is being processed.

The Data Subject receives the Privacy Request Confirmation email template.

Use Cases:

• Sending a confirmation email immediately after a request is submitted via API.
• Sending a confirmation email after identity verification has completed.

Then Extract Identifiers

This action triggers the extraction of additional identifiers for the Data Subject from configured integrations, before the request enters processing.

For more information on how identifiers work in DataGrail, see Multiple Identifiers.

Use Cases:

• Extracting a User ID or Service ID from a system of record so that downstream integrations can use it to identify the Data Subject.

Process Integrations

This action allows you to execute one or many integrations for the given workflow phase. This action can be used multiple times in a workflow, in conjunction with other conditions and actions.

This node is always followed by the default "Then process all other integrations" node.

Selecting the ellipses (...) on this node provides the option to change how remaining integrations are processed:

Option	Description
Then process all other integrations	Process every remaining integration not explicitly included in workflow nodes. This is the default behavior.
Exclude Remaining Integrations from Request	Skip all remaining integrations, preventing any further integrations from processing on the request.
Then process global and matching group integrations	Only process global integrations (not assigned to any group) and integrations assigned to the same group as the request. This option is ideal for multi-brand customers who want automated workflows to respect brand boundaries.

Important Notes:

• If an integration is excluded from processing in the Extracting Personal Data state, it will also be excluded from processing in the Pending Delete state.
• On Deletion and Pause Processing requests, Direct Contact emails only send in the Pending Delete state. This integration type will not perform any action in a Process Integrations node in an Extracting Personal Data workflow.

Deny Request

Only available as the termination action in a workflow.

This action is equivalent to denying a request manually and will immediately move a request to Closed by Customer.

The Data Subject will receive the Privacy Request Denied Email Template as well.

Process Request

Only available in the Pending Action state as a terminating action.

This action is equivalent to selecting Process Request, moving the request forward to its next workflow phase and preventing any manual action from being needed.

Assign a Privacy Request to a User

This action allows you to assign a Privacy Request to a DataGrail user.

Then Exclude Integrations From Processing

Only available in the Pending Action phase.

This action allows you to deselect integrations from returning data to the requester or executing deletion in the Pending Delete phase.

This action is equivalent to unchecking an integration manually on a request in Pending Action.

Publishing

When you have completed your workflow, select Publish Workflow to make it live. If an existing workflow is already published in that phase, it will be unpublished in favor of the new one. Published workflows cannot be edited, but you can exit the workflow builder at any time to save an unpublished draft.

Impact of Publishing a Workflow

Once a workflow is published, both new and existing Privacy Requests that enter this workflow phase will be processed against it.

Request Processing

All Privacy Requests that enter the phase of a published workflow will be evaluated using it. To view the status of a workflow, review the integrations list on the Privacy Request Details page. The Integration Statuses will indicate where the Privacy Request is in the workflow.

Status	Description
Not Started - Will Process in a Workflow	Another workflow node is being evaluated before this integration is triggered.
Processing	The integration is running in your workflow through a "Process Integrations" or "Then process all other integrations" node.

Examples

The following examples demonstrate common automation configurations for different organizational needs.

Run Internal Integrations For Only Employee Requests

Scenario: Your organization needs to process employee privacy requests against HR systems (like ADP and Greenhouse) while routing non-employee requests only to customer-facing integrations.

Workflow Phase: Extracting Personal Data

Configuration:

• Add a Data Subject Relationship condition to check if the requester is a "Former Employee"
• If true: Process HR integrations (ADP, Greenhouse), then process all other integrations
• If false: Process only customer-facing integrations (e.g., Algolia, Datadog, Facebook Marketing, Klaviyo), then exclude remaining integrations from the request

Require Manual Intervention For Account Hold

Scenario: Your organization needs to flag requests for manual review when data is found in a specific system that indicates an account hold (e.g., legal hold, active dispute, or pending investigation).

Workflow Phase: Extracting Personal Data

Configuration:

• Add a Process Integrations action to query your system of record (e.g., ADP) first
• Add an If Data is Found condition for that integration
• If true: Assign the request to a designated team member for manual review, then exclude remaining integrations from the request
• If false: Process all other integrations normally

Isolate Test Integrations With a Test Policy

Scenario: Your organization wants to test new integrations without affecting production requests. By creating a dedicated test policy, you can ensure test requests only run against test integrations while production requests only run against production integrations.

Workflow Phase: Extracting Personal Data

Configuration:

• Create a dedicated test policy in your account (e.g., "Test Policy")
• Add a Request Policy condition to check if the request uses your test policy
• If true: Process only your test integrations, then process all other integrations
• If false: Process only your production integrations, then exclude remaining integrations from the request

Zero-Click Deletion

Scenario: Your organization wants to fully automate deletion request processing by skipping the manual review step in the Pending Action phase. This eliminates the need for a privacy manager to manually select "Process Request" for each deletion.

Workflow Phase: Pending Action

Configuration:

• Add a Privacy Right condition to check if the request is a Deletion
• If true: Use the Process Request action to automatically move the request to the Pending Delete phase
• If false: Complete the workflow and require manual review for other request types

Deny Requests When No Data Exists

Scenario: Your organization uses a primary system of record (e.g., Salesforce) as the source of truth for customer data. If no data is found in this system, there won't be data in downstream systems either, so the request can be automatically denied.

Workflow Phase: Extracting Personal Data

Configuration:

• Add a Process Integrations action to query your primary system of record first
• Add an If Data is Found condition for that integration
• If true: Process all other integrations normally
• If false: Deny the request since no data exists for the requester

Route Requests By Intake Source

Scenario: Your organization accepts Privacy Requests via both API and Intake Form. API requests come from authenticated sessions and do not require identity verification. Intake Form and Request Queue submissions must be verified before processing begins. All requests should have additional identifiers extracted before entering processing.

Workflow Phase: Initialization

Configuration:

• Add an If Request Source Is condition to check if the source is API
• If true (API): Add Then Extract Identifiers, then move the request to the next phase
• If false (Intake Form / Request Queue): Add Then Verify Identity to send an identity verification email
  • If verified: Add Then Extract Identifiers, then move the request to the next phase
  • If not verified: Deny the request