Replacing Legacy ATS Auto-Response with Power Automate in Dynamics 365

A secure, cloud-native pattern for candidate communications when built-in ATS methods rely on deprecated authentication.

Overview

When integrating a Dynamics-based Applicant Tracking System (ATS) with a modern Microsoft 365 tenant, a common issue appears quickly: older auto-response mechanisms frequently rely on legacy email authentication methods that are no longer supported. This post documents an anonymized, real-world approach to replacing an ATS’s native auto-responder with a fully Microsoft-native solution built on Power Automate, Dataverse, and Exchange Online.

The result is a secure, scalable, and maintainable candidate auto-response system that stays entirely within Microsoft 365, eliminates the need for unsupported infrastructure, and can be expanded over time.

The problem

The ATS included an out-of-box candidate auto-responder, but it was built on older technology patterns that assumed legacy SMTP authentication. In modern Microsoft 365 environments, those authentication methods (notably Basic Auth) are deprecated and typically disabled.

A common workaround is to build and maintain a simple SMTP relay service to keep the ATS feature functioning. In practice, this introduces:

Security risk from legacy protocols and credentials
Operational overhead (another server/service to patch, monitor, and maintain)
Complexity during audits, incident response, and change management
Misalignment with a cloud-first, Microsoft-native architecture

The solution: Power Automate + Dataverse

The cleanest path forward was to replace the legacy auto-responder entirely with a Power Automate cloud flow, triggered by Dataverse events and sending mail through Exchange Online using modern authentication. This keeps the entire workflow inside the Microsoft ecosystem, simplifies support, and aligns to security best practices.

Trigger: Dataverse (Dynamics 365) event
Logic: Power Automate (Premium)
Email: Exchange Online “Send an email (V2)”

Key design requirement: only respond to web applicants

One important constraint: not every application record should trigger an email. Only submissions originating from the public-facing web application form should receive the automatic response.

To enable that, a small extension was added to the application entity:

Field: “Web Applicant” (Yes/No choice)
Behavior: Set to “Yes” when the application is created via the web form
Purpose: Allow the flow to conditionally send email only for web submissions

Flow architecture (high level)

The automation is implemented as a single cloud flow that triggers when a new application row is created in Dataverse. The flow checks whether the record is web-originated, enriches the record with related data, and sends the email.

Step 1 — Trigger on new application

Create a Cloud automated flow using the Dataverse trigger:

Trigger: “When a row is added, modified or deleted”
Change type: Added
Table: Applications
Scope: Organization

A common gotcha here is environment selection: the flow must be created in the same Power Platform environment where your Dataverse (CRM/ATS) data lives, or you won’t see the correct tables/entities.

Step 2 — Normalize the Yes/No flag for reliable conditions

In Dataverse, Yes/No and choice fields often appear as numeric values in outputs. A practical pattern is to initialize a string variable with the flag value, then evaluate it consistently.

Initialize variable: VarWebApplication
Type: String
Value: Dynamic value from the trigger (the “Web Applicant” field output)

In this implementation, the “Yes” selection resolved to a numeric value (commonly 100000000). Storing it as a string made the condition logic predictable.

Step 3 — Condition: only proceed for web applicants

Add a condition that checks the variable value. A simple and effective approach is:

Condition: VarWebApplication contains string(100000000)

Only the If yes branch needs actions. The If no branch can be left empty or used for logging.

Step 4 — Enrich the email with related data (Contacts + Jobs)

The application row typically doesn’t contain all the candidate-facing data you need. Two common pieces of information required for a strong response email are:

The candidate’s email address
The job title (or requisition name)

Lookup 1: Contact email

Use a Dataverse “List rows” action against the Contacts table. The application row includes a candidate reference value that matches the contact record ID. Filter the Contacts table where the contact ID equals the application’s candidate reference.

Lookup 2: Job title

Use another “List rows” action against the Jobs table. The application row includes a job reference value that matches the job record ID. Filter the Jobs table where the job ID equals the application’s job reference.

Step 5 — Send the email (Exchange Online)

With the related data retrieved, add Send an email (V2):

To: Candidate email (from Contacts lookup)
Subject: Include job title (from Jobs lookup)
Body: Use a simple template and optionally include job title and next steps
From: A shared mailbox or recruiting address (delegated)

As you add dynamic content from “List rows” actions, Power Automate will often wrap your email action in Apply to each loops. This is expected because “List rows” returns an array — even if you expect a single match.

Identity, licensing, and permissions model

Because this solution crosses Dataverse and Exchange Online, it benefits from an intentionally designed service identity. In this pattern, a dedicated service account owns the flow connections and has the appropriate licensing to run premium automation.

Power Automate: Premium capability (Dataverse trigger/actions)
Dataverse: Access to the environment and relevant tables
Exchange Online: Mailbox access and the ability to send mail

Delegated sending

If the external email should appear from a recruiting inbox rather than the service account, configure mailbox delegation so the service account can send from that address. Common configurations include Send As and/or Send on Behalf, depending on your org’s standards.

Benefits of this approach

Security: Eliminates reliance on legacy authentication and avoids standing up SMTP infrastructure
Simplicity: Fully Microsoft-native design (Dataverse + Power Automate + Exchange Online)
Maintainability: Centralized logging, monitoring, and change control in Power Platform
Extensibility: Easy to expand into multi-step candidate journeys and downstream HR workflows

Lessons learned

Dataverse choice/Yes-No fields may resolve to numeric values; validate outputs early and normalize them.
Expect “List rows” to return arrays and Power Automate to insert “Apply to each” loops automatically.
Environment selection matters — build the flow in the same Dataverse environment as your ATS/CRM data.
Plan service identity, licensing, and delegated sending up front to avoid late-stage redesign.

Conclusion

This modernization pattern replaces an unsupported ATS auto-responder with a cloud-first Microsoft solution that is secure by design, operationally simple, and highly reusable. Whether you’re integrating HR systems, customer intake forms, or CRM workflows, Dataverse-triggered Power Automate flows provide a reliable foundation for communication automation without legacy infrastructure.

Blog