Eng 2185 finalization and email for consent tasks

[JadeCara]

Ticket ENG-2185

Description Of Changes

🎯 Request for Consent finalization allowing for the option for manual sign off. This setting will default to not being turned on, but can be enabled in the config.

In this PR added a consent finalize option to config. This config option is not enabled by default and must be turned on. When a consent DSR is finalizing it checks for the setting and will either complete or wait for finalization. I also added a consent finalization email template which is not enabled by default and must be turned on by the user.

Code Changes

• ts files:
  • clients/admin-ui/src/features/messaging-templates/CustomizableMessagingTemplatesEnum.ts
  • clients/admin-ui/src/features/messaging-templates/CustomizableMessagingTemplatesLabelEnum.ts
  • clients/admin-ui/src/features/messaging-templates/CustomizableMessagingTemplatesLabelEnum.ts
  • clients/admin-ui/src/types/api/models/MessagingActionType.ts
  • clients/privacy-center/types/api/models/MessagingActionType.ts
• Added new template to src/fides/api/models/messaging_template.py
• Added new message to src/fides/api/schemas/messaging/messaging.py
• Updated src/fides/api/service/privacy_request/request_runner_service.py with both new finalize check and new messaging call
• Added finalize configs to config proxy src/fides/config/config_proxy.py
• Added new config to src/fides/config/execution_settings.py
• Updated all associated tests

Steps to Confirm

1. Run with fidesplus pointed at this back end.
2. First test to make sure the new consent_request_finalization_required execution setting can be updated using config_proxy.

PATCH /api/v1/config

{
  "execution": {
    "consent_request_finalization_required": true
  }
}

Verify that in the returned response the value is true

3. From the Privacy Center we need to do a consent request. (http://localhost:3001/ if running locally). We want it to create a DSR which means it must be configured for your area.

• If you are not in the US you can add a new privacy center to http://localhost:3000/consent/privacy-experience with a privacy center component or update the US Privacy Center with wherever you are. Either way it must be enabled on the experience page.
• The notices on the privacy center must be enabled and have system wide enforcement. You can set this by going to http://localhost:3000/consent/privacy-notices enabling the notices and then clicking in to them to set the enforcment to system wide.

• Lets turn on the consent email notification as well. (http://localhost:3000/notifications/templates) enable the one at the end (Consent request completed) - you may need to set a property for it, the default is fine.

4. Now you can make that consent request. It will take a second because it also uses celery workers but it should come through in the Request Manager (http://localhost:3000/new-privacy-requests) and show that it requires finalization.

Note: if it shows completed you might need to restart your worker (especially if it was running before you pulled this in for testing.

5. Finalize the request and then check your emails - you can also test that updating the template works here too.

6. Finally - set the consent_request_finalization_required back to False (step 2) Send through another consent request. The DSR should create but go straight to completed when finished. (if you still have email enabled you will receive another email - I edited the text on this one :) )

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
fides-plus-nightly	Ready	Preview, Comment	Dec 15, 2025 3:08pm

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
fides-privacy-center	Ignored		Dec 15, 2025 3:08pm

[codecov]

Codecov Report

❌ Patch coverage is 78.26087% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.29%. Comparing base (7108d26) to head (efbaa45).

Files with missing lines	Patch %	Lines
.../service/privacy_request/request_runner_service.py	77.77%	6 Missing and 2 partials ⚠️
.../api/service/messaging/message_dispatch_service.py	50.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7102      +/-   ##
==========================================
- Coverage   87.30%   87.29%   -0.02%     
==========================================
  Files         533      533              
  Lines       35090    35121      +31     
  Branches     4067     4073       +6     
==========================================
+ Hits        30635    30658      +23     
- Misses       3570     3576       +6     
- Partials      885      887       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds consent request finalization and email notification capabilities, mirroring the existing erasure finalization workflow.

Key Changes

• New Configuration: Added consent_request_finalization_required setting (defaults to False) to enable manual approval for consent requests before completion
• Finalization Logic: Extended finalization checkpoint to handle both erasure and consent requests based on their respective config settings
• Email Notifications: Added PRIVACY_REQUEST_COMPLETE_CONSENT messaging template and dispatch logic for consent-only requests
• Email Prioritization: Access/erasure completion emails take priority over consent emails when multiple action types exist in a single request
• Test Coverage: Comprehensive test coverage across DSR 2.0 and 3.0 for finalization behavior and email dispatch

Implementation Notes

The logic correctly distinguishes between consent-only requests (which now get consent completion emails) and mixed requests with access/erasure rules (which continue to get access/erasure emails). The finalization logic uses ConfigProxy for dynamic config resolution and properly checks for finalized_at to determine whether to require manual finalization.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation follows established patterns (mirrors erasure finalization), has comprehensive test coverage across both DSR versions, includes proper error handling, and defaults to disabled for backward compatibility. The logic is well-structured with clear prioritization rules.
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
src/fides/api/service/privacy_request/request_runner_service.py	4/5	Added consent request finalization logic and consent completion email functionality. Logic properly checks for consent rules and config setting, and sends appropriate emails for consent-only requests (separate from access/erasure).
src/fides/config/execution_settings.py	5/5	Added consent_request_finalization_required boolean config setting (defaults to False) following the existing pattern for erasure_request_finalization_required.
src/fides/config/config_proxy.py	5/5	Added consent_request_finalization_required to ExecutionSettingsProxy to expose the new config setting through the config proxy pattern.
src/fides/api/models/messaging_template.py	5/5	Added PRIVACY_REQUEST_COMPLETE_CONSENT template with default subject and body for consent completion notifications.
tests/ops/service/privacy_request/test_request_runner_service.py	5/5	Expanded test coverage for consent finalization scenarios across DSR 2.0 and 3.0. Tests verify finalization when enabled, no finalization when disabled, and consent completion emails.

[greptile-apps]

_{18 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[gilluminate]

LGTM

[JadeCara]

@greptile please review

[greptile-apps]

_{18 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[galvana]

I called out one issue but we should also check with @mfbrown to make sure we're not pausing system-generated consent requests.

[galvana]

There are some cases where we wouldn't want to pause the request for finalization even if the setting is enabled. I know this is at least the case for requests with a source of consent_webhook. These requests are system-generated and should just continue processing. You might want to check with @mfbrown if there are other sources that we want to exclude from this finalization (like Fides.js or Janus SDK).

[tvandort]

What would the impact of manualizing those be? I can imagine that if a notice was used on a website it might be too many DSRs to manually approve. But is there a technical reason beyond human workload?

[JadeCara]

Do we want to maybe add a specific type etc to the env var that way a user would turn on the finalization for the types they wanted explicitly?

[tvandort]

If we have to add this, that would be better yeah. My concern being that source should be more expansive than it currently is and I'd like some future wiggle room to define more of them.

[mfbrown]

I do think we should add a config to specify which sources require finalization. To the consent point, it would add a lot of manual work to a process that that could process many thousands of webhook responses, so I don't think we can put that work suddenly on customers for all requests.

I agree with @tvandort that we should add the ability to define more sources, more easily.