Automated Workflows

Automations allow customers can create workflows to programmatically define how each phase of a data subject request is processed. Workflows can be set for each phase of request processing. Workflows are driven by the ability for customers to define conditional sets for requests that can branch and add actions, such as selecting which integrations process, or how they process, and setting specific actions that need to occur for different processes.

DataGrail User Roles

Only users granted specific user roles will have access to this page. The following roles are able to view and interact with Automations:

• Super Admin
• Request

Workflow Phases

With automations, you can configure processing actions in three phases: Extracting Personal Data, Pending Action, and Pending Delete.

Each phase has specific functions in the DataGrail application and can affect the following phase. Below are examples of Privacy Request functions that are available today without automation.

For more information on how each phase functions without automations: Request Lifecycle Overview

Definitions and Terms

Term	Definition
Node	A node represents a condition or action. In the UI, it appears as a box connected by directed lines to one or more other boxes (nodes).
Condition	A piece of logic that verifies whether a condition (or set of conditions) holds. It will return a single boolean value, true or false (i.e. policy == 'GDPR'). This allows DataGrail to create branching logic within our workflow (i.e. if X, do Y, else do Z).
Action	A node in which some action is taken (i.e. sending an email to the user). In the above case, most actions will likely accept some parameters, such as one or more email addresses.
Workflow Phase	The Privacy Request workflow state affected by the automation.

Creating An Automated Workflow

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

Selecting Automations will take you to the Automations Home Page, which shows all workflows that you have created and published.

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

When building a workflow, there are two types of nodes: Conditions and Actions. Select the "+" button to add a condition or action. This will open a drawer with options for selecting actions or conditions.

Conditions

Supported Conditions

Several conditions can be utilized in workflows. Some conditions are only available in specific phases or can only precede certain actions.

Request Policy

Request Policies can be utilized as a condition; the condition evaluates what policy a Privacy Request falls under. The request policies in the DataGrail application are connected to location and can be used as a proxy for location. The workflow dropdown contains all available privacy policies.

Privacy Right

The Privacy Right condition evaluates the type of privacy right that is available. The values are not dynamic to the request policies selected, meaning that the values shown are static and will always be shown. Privacy Rights that are available for use for conditions are:

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

note

"Opt-Outs" and "Do Not Sell or Share" are not available for workflows.

Data Subject Relationship

The Data Subject Relationship field can be configured on the request policy. Only DataGrail's standard Data Subject Relationship values can be used in workflows:

• Business Contact
• Customer
• Employee
• Former Employee
• Job Applicant
• Other

If Data is Found

The If Data is Found condition is only available in the Extraction and Pending Delete phases, and can only be added following a Process Integrations action. It evaluates whether or not data is found after a processing step.

Time Bound Trigger

The time-bound condition can only be added to a processing step. This condition evaluates the days until a processing tier is initiated. This is done by configuring the number of days a tier will wait until all the integrations in that tier are processed.

Once the configured time condition is met, the workflow will allow the proceeding tier to begin processing if the tier has not finished processing. This will not affect the processing of the integration that did not process; that integration (or integrations) will continue to process unless manually skipped in the UI.

You must first add a processing integration step for a time-based condition. Once a step has been added, you can navigate to the ellipses (...) in the node to edit or add a time-based condition. If you delete the node associated with a time-based condition, the time-based condition will be removed from the workflow.

Once you have selected Add Time Rule, a drawer will appear for customers to add a time-based trigger. Once added, the condition will be added to the workflow state in a separate node.

Time Rule Values

Users can only input integers, and the unit of measure is always in days. Users who input numbers outside 0-99 will receive an error and cannot apply the condition.

Adding a Condition

Conditions can be used to define specific processing scenarios. For example, you can create a specific processing scenario based on a request policy, privacy rights, or the data subject relationship field. Conditions utilize "and/or" logic so you can use multiple conditions in the same node.

To begin creating a condition node, select Add a Condition and select which condition you would like to start with. Some conditions can only proceed other conditions and will not appear when adding the first condition.

This will bring up a secondary drawer where multiple conditions can be selected. Any available condition can be utilized from the Add Another Condition section. When a condition set contains multiple conditions, there is always an And operator between the two. Or operators can only be added in the same condition using the +Add Value button.

When adding a condition, specific values must be selected via the dropdown. Values are the inputs. For example, the values for Privacy Right will be deletion, download, etc.

Example

Below is an example of a condition utilizing multiple conditions and values. In this example, the condition set reads, "If Policy is CPRA and the Privacy Right is Download or Delete, and the Data Subject Relationship is Employee or Former Employee."

Once a condition node has been applied to another workflow, the workflow will split into two branches: a true branch and a false branch.

Default Branches

All new branches generated in the Extraction Phase will automatically have the Process all unselected integrations and another node for Complete workflow. When adding a condition, if the existing processing all other integrations has been configured to skip, that configuration is preserved and is sent to the true branch.

Conditions can be added to different branches. Some conditions and actions can only be used after specific workflow criteria are met (for example, the data is found condition can only be utilized if a processing step precedes it).

Actions

Supported Actions

Actions can be utilized in a workflow to automate manual steps within DataGrail programmatically.

Process Integrations

This action allows you to select which integrations to process within a workflow. Integrations can be used multiple times and are not filtered. In combination with the default Skip Processing Node, it will omit all other integrations or can be used to determine a sequence for processing integrations.

Deny Request

The Deny Request action stops the Privacy Request from processing and moves it to a closed state. Once denied, the data subject will receive an email confirming the denial of their request using the Privacy Request Denied Email Template.

The Deny Request action can only be added as a terminating action.

Process Request

The Process Request action automates the final "button push" for the Pending Action state, moving the request to its final processing state. This action is only available in the Pending Action state and can only be added as a terminating action.

Assign a Privacy Request to a User

This action allows you to assign a specific Privacy Request type to a DataGrail user. Before the action node is added to the workflow, a DataGrail user must be assigned to it.

Process/Skip All Other Integrations

This action is a default action in the Extraction phase, which processes all configured integrations.

Example

In a workflow that defines a specific condition set (e.g., Employee or Former Employee DSRs), while we can set particular processing for that condition, we still want all Privacy Requests that do NOT meet that condition to be processed.

If a workflow only needs to consider specific integrations, then you can edit the default node(s) necessary to skip processing all other integrations. This allows you to define a particular set of integrations to process rather than processing all integrations.

The default for this final node will be Process All Integrations. To update this node to Skip all integrations, you will edit the node by using the ellipses (...) and selecting Edit.

This will open the edit drawer and provide a drop-down menu for you to select the preferred processing action.

Exclude Integration

This action is only available in the Pending Action phase. You can use this action to exclude integrations from returning data in a download or the deletion phase. This action will allow you to programmatically exclude integrations from processing, similar to the integration or file down-selection in the application today. Any integration or sets of integrations can be selected for exclusion.

Adding an Action

Action can be added in various places in a workflow. Certain actions are only available after a specific condition is met or at a terminating point in a workflow phase. Actions Nodes are denoted by a lightning bolt icon (⚡️).

To create an action node, you must select its placement in a workflow. This can be done by choosing the "+" button on the workflow. Once the node's placement has been defined, you can select Add an Action in the drawer.

Once selected, some configuration may be involved in adding the action. We use the assign Privacy Request to a user action in this example. In this case, we must select a valid DataGrail user.

Once a user is assigned, we can apply the action, creating an action node in the workflow.

Publishing

Multiple workflows can be created simultaneously, but only one can be published per phase. Once a workflow is published, any Privacy Request that meets the criteria set in the particular workflow phase will be processed according to the workflow phase.

The workflow rules and tiering are evaluated when a workflow is in the extraction or deletion phase. When a Privacy Request is in the extraction or deletion phase, its workflow is continually evaluated. Evaluation proceeds through the workflow until an incomplete node is reached.

For example, an action node to process specific integrations will block further workflow processing until those integrations have been completed. It will fire if the criteria to begin processing that integration are valid (e.g., if the integration tiers in front of it have run or a specific amount of time has passed). If an integration does not meet that criteria, it will continue to hold and be deferred.

Publishing a workflow is done by selecting Publish Workflow, which is permanently anchored at the top of the workflow screen.

This will prompt you with the following modal:

Once you select Publish Workflow, the published workflow will be available on the Automations page, marked as Published.

Workflow Statuses

To view the status of a workflow, you will need to review the integrations on the DSR details page. The DSR Details page will display specific statuses when processing. The different Integration Statuses that are involved are:

Not Started - "Will process in a workflow"

Processing

The Privacy Request will be completed and closed when all integrations are processed.

Frequently Asked Questions, Examples, & Videos

How are requests processed without workflows?

This is a video that walks through how Privacy Requests are processed without workflows.

Can I deny requests based on location or request policy?

Location-based or Policy denials can be created in workflows to allow customers to only action on requests where privacy rights are granted. Here is an example.

Can I build a workflow to process an employee DSR?

Here is an example of setting up a workflow in the access phase to manage a workflow to process an employee DSR. This example reviews conditional logic and branching. It also shows you how to process only specific integrations for employees or former employees.

How do I created a tiered deletion workflow?

Tiered processing allows customers to stop the downstream repopulation of data. Customers can do this by setting the sequence for deletion and adding time-based triggers to ensure they stay within their request times. Here is an example.

How does branching work?

Branching through conditions can allow you to generate multiple use cases in the same phase. In this example, we walk through how to build more than one use case in the same workflow.

How do automations affect request processing?

Integration sequencing can be configured in the Extraction and Pending Delete phases. You can group integrations by node and define the next steps in processing or add time-based triggers to allow the following tier to process after a configured amount of time.

When do workflows affect privacy requests?

When a workflow is published, the workflow is applied to all Privacy Requests that meet the criteria during any processing phase. If a workflow is unpublished, workflows being evaluated at that time will be processed by the default processing (all integrations fire simultaneously).

How does integration sequencing affect processing?

The sequencing automated workflow allows you to define the processing sequence for their integrations. Therefore, to ensure that data is deleted or retrieved in a manner that does not allow it to repopulate, a customer must select their Tier 1 systems or the integrations that contain sources of truth (that can populate data in downstream systems) in the first set of integrations.

Once the Tier 1 systems are established, a customer can add another node to allow for processing integrations with data dependencies on the Tier 1 systems and can continue adding tiers based on data dependencies.

For integrations that are NOT selected, these will fire alongside the final tier to ensure no issues with repopulation.

How do time-based triggers affect processing?

The only condition that can be set for the processing step and workflows containing integration sequencing is a time-based condition trigger. Customers can configure the number of days a tier will wait until all the integrations in that tier are processed. Once the configured time condition is met, the workflow will allow the subsequent tier to begin processing if the tier has not finished processing. This will not affect the processing of the integration that did not process; that integration (or integrations) will continue to process unless manually skipped in the UI.

How do time-based triggers affect processing?

The only condition that can be set for the processing step and workflows containing integration sequencing is a time-based condition trigger. Customers can configure the number of days a tier will wait until all the integrations in that tier are processed. Once the configured time condition is met, the workflow will allow the subsequent tier to begin processing if the tier has not finished processing. This will not affect the processing of the integration that did not process; that integration (or integrations) will continue to process unless manually skipped in the UI.

How are "stuck" DSRs handled with workflows?

DSRs that are "stuck" (an integration or integrations are holding up the completion of the Privacy Request) will be picked up by our daily job for stuck Privacy Requests. This job runs daily and will continue to retry processing until the errors are fixed and the integrations are considered completed.