If your business runs on Microsoft Dynamics 365, your customers, vendors, accounts, and transactions all live inside Dataverse. Your compliance team's screening process, however, probably doesn't. The result is a familiar pattern: a new customer is created in Dynamics 365 Sales, a new vendor is set up in Dynamics 365 Finance, a purchase order moves to "approved" in Supply Chain Management... and someone, somewhere, has to remember to run a sanctions check before the relationship goes live.

This is the kind of friction that low-code automation eliminates. Microsoft's Power Automate (formerly Microsoft Flow) is built into the Power Platform alongside Dynamics 365 and Dataverse. With a few well-designed flows, you can call the sanctions.io Screening API and Monitoring API directly from D365 events to trigger sanctions, PEP, and watchlist checks the moment a record is created or updated. And this can be done without writing custom plug-ins or shipping new code.

In this article, we'll walk through how to use Power Automate to connect Dynamics 365 to the sanctions.io API across two distinct use cases: Screening (event-driven, point-in-time checks) and Monitoring (continuous, ongoing surveillance against sanctions lists, PEP databases, and watchlists). We'll cover real-world patterns across Dynamics 365 Sales, Customer Service, Finance, Supply Chain Management, and Business Central, with a focused section on data quality and the best practices we've seen work for our customers across financial services, fintech, and other regulated industries.

‍

Screening vs Monitoring: Choosing the Right Approach

Before opening Power Automate, it's worth being clear about which sanctions.io API you actually need, because the two products solve fundamentally different compliance problems.

The Screening API is stateless and event-driven. You send a name (and ideally a country, date of birth, or other identifier), and you receive an immediate response with any matches against sanctions lists, PEP databases, criminal watchlists, or high-risk jurisdictions. Once the response is returned, the data is gone from our side and nothing is stored. This is the right tool for customer onboarding in Dynamics 365 Sales, vendor onboarding in Finance or Supply Chain Management, transaction screening, and any situation where you need a one-time decision: "Is this person or entity safe to do business with right now?"

The Monitoring API is stateful and continuous. You add an entity to your monitoring list once, and sanctions.io re-screens it automatically every time the underlying watchlists update. This happens every 60 minutes. When a status changes (a new match appears, an existing record is removed from a list, an alias is added), you receive a real-time alert via webhook or polling. This is the right tool for ongoing relationships: customers you continue to serve, vendors you continue to pay, counterparties you continue to transact with.

Most compliance programs running on Dynamics 365 need both. A typical pattern is to use the Screening API for the initial onboarding check, and then add the entity to the Monitoring API for ongoing surveillance. Power Automate can orchestrate both flows natively, with Dataverse as the system of record.

‍

Part One: Sanctions Screening in Dynamics 365 with Power Automate

The Pattern

A screening flow in Power Automate typically follows this structure:

1. Trigger — a Dataverse event (row created, row updated, status change) in the relevant D365 app
2. Action 1 — call the sanctions.io Screening API via the HTTP connector
3. Action 2 — parse the JSON response and evaluate it with a Condition
4. Action 3 — write the result back to the Dataverse row, log it for audit, and notify a reviewer if a match is found

Example 1: Customer Onboarding in Dynamics 365 Sales

The most common starting point for D365 customers is automating sanctions screening at the point of lead or account creation in Dynamics 365 Sales.

Trigger: Dataverse "When a row is added, modified or deleted" — Table: Account, Change type: Added.

Action — HTTP (Premium connector):

• Method: GET
• URI: https://api.sanctions.io/search/
• Headers:
  • Authorization: Bearer YOUR_API_TOKEN
  • Accept: application/json; version=2.3
• Queries:
  • name: dynamic content from the Account's name field
  • country: ISO two-letter code from address1_country (or a Compose step that normalizes the country)
  • entity_type: Entity
  • min_score: 0.88
  • data_source: sanctions-lists,pep,crime

Parse JSON the response using the schema published in the sanctions.io API reference, then add a Condition: if length(body('Parse_JSON')?['results']) is greater than 0, branch into the "match found" path.

Follow-on actions:

• Update the Account row — set a custom sio_screening_status column to Match - Review Required, store the matched entity's name and source list in sio_match_details, and timestamp sio_last_screened_on.
• Create a Dataverse row in a custom sio_screening_audit_log table with the request payload, response payload, timestamp, and the user who triggered the event.
• Post an Adaptive Card to a Microsoft Teams channel monitored by the compliance team.
• Optionally, create a Dynamics 365 Customer Service case assigned to the on-call compliance reviewer.

Example 2: Vendor Onboarding in Dynamics 365 Finance and Supply Chain Management

Vendor masters in Dynamics 365 Finance and Supply Chain Management are one of the highest-value places to embed sanctions screening. New vendors are created constantly, often by procurement staff outside the compliance function, and a missed sanctions match on a supplier can expose the entire organization to serious enforcement risk.

The trigger here is the creation or modification of a Vendor record. Power Automate connects to Finance and Supply Chain Management via the Dataverse connector when finance and operations apps are virtualized into Dataverse, or via the Fin & Ops Apps (Dynamics 365) connector when working with the legacy data entity model directly.

The HTTP call structure is identical to Example 1, with two important differences:

• entity_type should be set to Entity
• The name field should map to the vendor's legal name (not the display name or DBA), which in Finance is typically Name on the VendorV2 data entity

On a match, your flow should:

• Set a vendor compliance status field (custom or via the standard OnHold flag) so the vendor cannot be used in transactions until reviewed
• Create a Microsoft Dataverse row in your audit log
• Notify procurement and compliance via Teams or email

Example 3: Transaction Screening in Supply Chain Management and Business Central

For payment runs and purchase orders, the highest-value trigger is a record moving to an "approved" or "ready to pay" state. Screening at this point catches not only the vendor but also any beneficiary or remittance party that might have changed since the original vendor onboarding check.

This pattern works identically in Dynamics 365 Business Central for smaller organizations, where the standard Business Central connector provides triggers on Vendor, Customer, and Purchase Order records.

Two important refinements for transaction-scale flows:

• Use the Batch Screening endpoint (POST /search/batch/) when an event involves multiple parties — for example, a payment run with hundreds of beneficiaries. Single-search endpoints are designed for sub-second response on one record at a time; batch screening is designed for volume and processes thousands of records asynchronously.
• Block the downstream action until the screening returns clean. Use Power Automate's parallel branches and the Terminate action to ensure that a "Release Payment" branch only fires when no matches above the threshold are found, otherwise routing to a "Hold for Review" branch that updates the record and creates a case.

Example 4: Periodic Re-Screening of the Existing Customer Base

Power Automate's Recurrence trigger is well suited for periodic batch screening of your existing Dataverse population. This is useful for compliance programs that aren't ready to adopt continuous monitoring but want quarterly or monthly re-checks.

A recurrence flow fetches all Account rows with a sio_last_screened_on value older than 90 days, loops through them, and calls the Screening API for each. For populations larger than a few hundred records, switch to the batch endpoint and use a Until loop to poll for completion — the synchronous loop pattern will hit Power Automate's throttling limits quickly.

Reading the Response

The Screening API returns a JSON response with a results array. Each result includes the matched entity's name, aliases, addresses, dates of birth, nationality, the source list (data_source.short_name), and a confidence score. The presence of any result in the array — given that you've already filtered by min_score in the request — is your signal that human review is needed.

A common mistake we see in early flows is treating any response with HTTP 200 as "clear." A 200 response simply means the API worked; you must inspect the results array length in your Condition step to determine whether matches were found.

{{snippets-guide}}

Part Two: Continuous Monitoring in Dynamics 365 with Power Automate

Continuous monitoring is a different shape of integration. Instead of "screen this record now and tell me the answer," the flow is "remember this entity, watch it forever, and tell me when something changes."

This means a monitoring integration has two halves:

• Adding entities to monitoring when they're created in Dataverse
• Receiving real-time alerts when sanctions.io detects a status change, and routing those alerts back into Dynamics 365

Half One: Adding Dynamics 365 Records to Monitoring

The flow structure is similar to a screening flow, but the API call is different.

Action — HTTP (Premium connector):

• Method: POST
• URI: https://api.sanctions.io/monitoring/
• Headers:
  • Authorization: Bearer YOUR_API_TOKEN
  • Accept: application/json; version=3.1
  • Content-Type: application/json
• Body:

{

 "name": "Acme Industries Ltd",

 "country": ["DE"],

 "entity_type": "Entity",

 "external_identifier": "@{triggerOutputs()?['body/accountid']}",

 "min_score": 0.88,

 "data_source": ["sanctions-lists", "pep"]

}

The external_identifier field is the single most important parameter to set correctly. Use the Dataverse row's GUID (accountid, contactid, or the equivalent for vendor and customer tables in Finance and Supply Chain Management). This GUID is what makes the round-trip back to Dynamics 365 possible when an alert fires months later.

A mature monitoring integration also stores the monitoring entry's id (returned in the API response) on the source Dataverse row in a custom column like sio_monitoring_id. This gives you a direct handle for later updates or deletion if the customer or vendor is offboarded.

Half Two: Receiving Real-Time Alerts

Here Power Automate offers two paths.

The recommended path: webhooks. Configure a webhook endpoint in your sanctions.io account pointing at a Power Automate flow with a "When an HTTP request is received" trigger. When a new match is detected, sanctions.io pushes a monitoring_result payload to that URL in real time. The payload includes the external_identifier (the Dataverse GUID you set earlier), the matched entity details, the confidence score, and the source list. From there, your flow can:

• Use the GUID to look up the Account, Contact, or Vendor row in Dataverse directly
• Update its compliance status
• Create a Dynamics 365 Customer Service case for the on-call compliance analyst
• Post an Adaptive Card to a Teams channel with one-click "Approve" / "Investigate" / "Block" actions

The alternative path: polling. If your environment doesn't allow inbound webhooks (a common constraint behind enterprise firewalls), you can use a Recurrence trigger in Power Automate to call GET /monitoring/ on a regular cadence (e.g., every hour) and check for new alerts. This works, but it's less efficient as you're calling the API even when there's nothing new to report, and you introduce a delay between the alert and the action. We strongly prefer webhooks wherever feasible.

Example: End-to-End Vendor Monitoring across Finance, Teams, and Customer Service

A common pattern for a D365 customer looks like this:

1. Vendor created in Dynamics 365 Finance → Power Automate flow triggers on the new Dataverse row → calls the Screening API for the immediate check → calls the Monitoring API to add the vendor to ongoing surveillance with the Dataverse GUID as external_identifier.
2. sanctions.io detects a match six months later (the vendor's beneficial owner has been added to a PEP list) → webhook fires to the Power Automate HTTP trigger.
3. The flow receives the payload → uses the external_identifier to look up the vendor in Dataverse → updates the vendor status to "Compliance Hold" → posts an Adaptive Card to the #compliance-alerts Teams channel with match details → creates a Dynamics 365 Customer Service case assigned to the on-call compliance analyst.

The reviewer investigates inside Customer Service, confirms whether it's a true match or false positive, and updates the monitoring entry status via the API (or the Monitoring Portal). The audit trail is preserved automatically in both Dataverse and sanctions.io.

Data Quality: The Foundation of Accurate Screening

No automation platform, Power Automate or otherwise, can compensate for poor input data. The accuracy of every sanctions, PEP, and watchlist match comes down to the quality of the parameters you send to the API. Before you build a single flow, take a hard look at what your Dataverse tables actually capture, and whether those fields are reliably populated.

Here's the minimum dataset we recommend for each entity type.

Screening Persons (Individuals)

For individuals in Dynamics 365 — typically Contact rows, or Customer records of type "Person" — three fields do the heavy lifting:

• Full name — the legal name, ideally as it appears on a government-issued document. Avoid nicknames, abbreviations, or initials where possible. Our matching algorithm handles transliteration and common variations, but a complete legal name produces the most accurate results. In Dataverse, this typically means concatenating firstname and lastname rather than relying on fullname alone.
• Date of birth — formatted as YYYY-MM-DD. If only the year is known, YYYY is also accepted. Date of birth is the single most powerful identifier for reducing false positives on common names — a single date of birth can eliminate dozens of irrelevant matches. The standard Dataverse birthdate column maps cleanly with a formatDateTime() expression in Power Automate.
• Country of residence or nationality — accepted as either an ISO two-letter code (DE, US, GB) or the full English country name. Where you have both nationality and country of residence, send the more compliance-relevant one for your use case.

Optional but valuable identifiers include passport number, national ID, or tax ID, all of which can be passed in the identifier field for additional precision. In D365, these are often held in custom columns or on the Customer entity in Finance.

Screening Organizations (Entities)

For organizations — Account rows in Sales, Vendor and Customer (Organization type) in Finance and Supply Chain Management — the equivalent minimum dataset is:

• Legal name — the registered legal name of the entity, including any legal suffix (Ltd, GmbH, Inc., LLC, S.A.). Our algorithm automatically normalizes common legal suffixes, so you don't need to strip them manually — sending the full legal name actually improves match accuracy.
• Country of incorporation — where the entity is legally registered, as an ISO two-letter code or English country name. This is more compliance-relevant than the country of operation, which can differ. Be careful in D365: the standard address country on an Account is often the operating address, not the country of incorporation. Many of our customers add a dedicated sio_country_of_incorporation column on Account and Vendor tables.
• Entity type — set to Entity to ensure the screening targets the correct subset of watchlists.

Optional but useful identifiers include VAT number, tax ID, or company registration number. These become especially valuable for monitoring, where they help maintain a stable link between your records and the monitored entity over time. The Dataverse accountnumber field can be useful here but rarely contains an official registration number; a custom column is usually cleaner.

Screening UBOs (Ultimate Beneficial Owners)

Sanctions screening doesn't stop at the legal entity. Many regulatory regimes, and most prudent compliance programs, require screening of the natural persons who ultimately own or control the organization. A vendor or customer entity may be perfectly clean while one of its UBOs sits on a sanctions list, a PEP database, or an adverse media source.

A few important points on UBO screening in Dynamics 365:

• sanctions.io does not perform UBO discovery. UBO data (names, dates of birth, nationalities, ownership percentages) is collected through your KYC/KYB process or sourced from a corporate registry provider. Once you have it, those individuals can be screened through our API exactly like any other person.
• Model UBOs as related rows in Dataverse. A common pattern is a custom table sio_ubo with a many-to-one relationship to Account, Vendor, or Customer. Each UBO row holds the individual's full name, date of birth, nationality, and ownership percentage.
• Treat each UBO as an individual screening. When you receive UBO data alongside an organization, your flow should iterate over the related UBO rows: screen the entity itself, then screen each UBO using the individual parameters above. Power Automate's Apply to each action is well suited to this.
• For monitoring, register each UBO as its own monitoring entry. Use an external_identifier that ties the UBO back to the parent organization. For example, the UBO's Dataverse row ID, with the parent organization ID embedded in metadata or in a structured pattern like {vendorid}-UBO-{uboid}. This way, when an alert fires on a UBO six months down the line, you can trace it back to the vendor without ambiguity.
• Re-screen UBOs when ownership changes. UBO data is dynamic. Configure a Dataverse trigger on the sio_ubo table for Added and Modified events so that new UBOs are added to monitoring and changed UBOs are re-screened. When ownership ends, deactivate the monitoring entry rather than just deleting the Dataverse row. This preserves the audit trail.

A Simple Data Quality Checklist Before You Build

Before flipping a flow to production, ask:

1. Is the Dataverse column actually populated for the records that matter? (A column that exists in the schema but is blank for 60% of records is a problem.)
2. Are dates stored in a consistent format that can be transformed to YYYY-MM-DD with formatDateTime()?
3. Are countries stored as ISO codes, full names, or a mix? (You may need a switch step or a lookup table in Power Automate to normalize.)
4. Is there a stable, unique identifier you can use as the external_identifier? (The Dataverse GUID is almost always the right answer.)
5. For organizations, do you have access to UBO data? If not, is that something you need to address upstream in your KYB process before screening goes live?

The answer to these questions usually determines whether your screening integration delivers a clean signal or a flood of false positives. Time spent on data quality up front pays back many times over in reduced manual review.

{{snippets-case}}

Best Practices for Sanctions and AML Screening Automation in Dynamics 365

A few principles consistently separate Power Automate integrations that work from those that quietly fail at the worst possible moment.

Always start in the sandbox. sanctions.io provides a sandbox environment with a separate API token and a controlled test dataset. Use it alongside a Power Platform sandbox environment in Microsoft to build and test every flow before promoting to production. By design, sandbox tokens cannot authenticate against production endpoints and vice versa. Note that sandbox API calls do not count against your plan usage; production calls do.

Store API tokens securely. Never hard-code your sanctions.io API token in the HTTP action. Use Azure Key Vault (referenced via the Key Vault connector) or, for simpler deployments, the Environment Variables feature in Power Platform solutions. This keeps the token out of flow definitions checked into source control and makes rotation a single-point change.

Set min_score deliberately. We recommend 0.88 as a starting threshold. This balances false positives against missed matches for most use cases. Higher thresholds (0.90+) reduce review workload but increase the risk of missing relevant matches; lower thresholds catch more but generate more noise. Tune this based on the risk profile of the system you're integrating. A vendor master with high-value international payments warrants a lower threshold than a low-risk domestic customer base. For more guidance, see our Best Practices for Screening Parameters.

Always send an external_identifier. This is non-negotiable for production integrations. For Dynamics 365, the Dataverse row GUID (accountid, contactid, vendoraccountnumber in F&O, etc.) is the most stable identifier you have. Names and email addresses change; GUIDs don't.

Add entity_type, country, and date_of_birth whenever you have them. The more identifiers you provide, the more accurate the match and the fewer false positives you'll generate. For individuals, date of birth is particularly powerful: a single date of birth can eliminate dozens of false positives on a common name.

Use the Accept header to pin your API version. Always include Accept: application/json; version=2.3 for the Screening API, and version=3.1 for the Monitoring API. If you omit the version, the API defaults to legacy behavior, which can produce different results than you expect.

Build the audit trail in Dataverse. Don't rely on flow run history for compliance audit — flow run history is retained for only 28 days by default. Create a dedicated Dataverse table (sio_screening_audit_log or similar) that stores the request payload, response payload, timestamp, and the user or system that triggered the screening. Every screening event and every alert should be logged with enough detail to reconstruct what was checked, when, against which lists, and what the human decision was.

Handle errors and retries with the HTTP connector's built-in policy. Configure the Retry Policy on the HTTP action for transient 5xx errors (the default exponential backoff is usually appropriate). For 4xx errors, which typically indicate a configuration problem (wrong token, malformed request, invalid data source) use a parallel Run after branch with Has failed to alert your team via Teams or email.

Don't whitelist by deleting. When a reviewer determines a match is a false positive, mark it as such. Don't simply remove the entity from monitoring. The Monitoring API supports tagging results as False Positive or Real Positive along with explanatory notes. This preserves the audit trail and prevents the same false positive from being re-raised next time the underlying record changes.

Package flows as a solution. Use Power Platform Solutions to package your screening flows together with the custom Dataverse tables, columns, environment variables, and connection references they depend on. This makes promotion from development → test → production environments clean and repeatable, and gives compliance teams a single artifact to version and audit.

Know when Power Automate is the right tool , and when it isn't. Power Automate is excellent for orchestrating workflows across Dynamics 365 apps and the wider Microsoft ecosystem (Teams, SharePoint, Customer Service, Azure services). For very high-volume screening (tens of thousands of records per day) or where sub-100ms response times matter, a direct API integration from a Dataverse plug-in, Azure Function, or Logic App will serve you better. Use Power Automate where its strengths shine: rapid development, deep Dynamics 365 integration, and giving compliance teams the ability to evolve workflows without filing engineering tickets.

‍

Closing Thoughts

Dynamics 365 is where your customers, vendors, and transactions live. Therefore,  it's also where sanctions and AML compliance needs to happen. Power Automate, combined with the sanctions.io Screening and Monitoring APIs, gives compliance teams a practical way to embed sanctions, PEP, and watchlist checks into the everyday flow of business — from customer onboarding in Dynamics 365 Sales, to vendor onboarding in Finance and Supply Chain Management, to payment approval in Business Central — without waiting for an ISV connector or a custom plug-in project.

Start with one flow. Get it right in the sandbox. Promote it through your solution pipeline to production. Then build the next one. Within a few weeks, you'll have a connected compliance layer that scales with your Dynamics 365 environment rather than blocking it.

If you'd like help designing the right integration pattern for your Dynamics 365 stack, our team is always happy to walk through it with you. Reach out at help@sanctions.io or book a session with us. We've seen most of the patterns and we're glad to share what works.

‍

Related Articles

Best Practices for Screening Parameters

Using Low Code Platforms

Monitoring API

Covered Sanctions Lists & Watchlists

Sandbox Environment