Validate Addresses with Power Automate: PostGrid (Unbound Action)

Overview

Address Validation for Dataverse exposes PostGrid address verification as two Dataverse unbound actions. Power Automate can call them with the standard Microsoft Dataverse connector and its Perform an unbound action step:

PostGrid sells these as two separate products, with their own endpoints, results and billing. They are therefore two actions, not one action with a country switch, so a flow never silently changes which product (and which billing) it uses. The example flow in this article routes each contact to the right action based on its country.

Both actions return a standardized address, a precise verification status, and a list of missing components. They do not update any record. Your flow decides whether the result is good enough to write back.

Before you start

• Address Validation for Dataverse is installed in a version that includes the PostGrid actions (sharpxrm_VerifyWithPostGrid appears in the Action Name list).
• A valid Address Validation license that includes the PostGrid add-on. Without it, the actions return ResultFound = Failed with the message There is a problem with the product licence. Please contact the administrator.
• A PostGrid account with address verification enabled.
• An active API Configuration row with Validation Service Type = PostGrid API that holds a secret key (live_sk_… or test_sk_…). The actions run on the server, so they need a secret key. A public key (live_pk_…) is rejected with an allowed-origins restriction error, because public keys only work from registered browser origins. If you also use the PostGrid autocomplete control, create two API Configuration rows: one with the public key for the control (for example PostGrid Autocomplete), and one with the secret key for verification (for example PostGrid Verify).
• A Microsoft Dataverse connection in Power Automate.

Cost: PostGrid bills per lookup. Each verification uses one lookup, plus one more when IncludeGeocoding is Yes. Test keys (test_sk_…) use no lookups but return dummy data, so they are useful for building a flow but not for checking results.

How the example flow works

1. When a row is selected (Contacts): users run the flow from the Flow menu on a contact.
2. Contact ID (Compose) and Get contact (Get a row by ID): read the Address 1 columns, including latitude and longitude.
3. Get PostGrid configuration (List rows) and Configuration found (Condition with a Terminate in the False branch).
4. Is US or Canada (Condition): sends US and Canadian addresses to sharpxrm_VerifyWithPostGrid and everything else to sharpxrm_VerifyWithPostGridInternational.
5. PostGrid result (Compose): merges the output of whichever action ran, so later steps have a single place to read from.
6. Is deliverable match (Condition): overwrites Address 1 only when PostGrid confirms the address is deliverable.

Find the API Configuration

Use List rows on APIs Configuration to find the secret-key record by name:

Route by country

The Is US or Canada condition compares this expression with true:

contains(createArray('US', 'USA', 'UNITED STATES', 'UNITED STATES OF AMERICA', 'CA', 'CAN', 'CANADA'), toUpper(trim(coalesce(outputs('Get_contact')?['body/address1_country'], ''))))

Add any other spellings your data uses. Contacts with no country go to the international action, because it covers every country.

Call the unbound actions

In each branch, add Microsoft Dataverse > Perform an unbound action. Choose sharpxrm_VerifyWithPostGrid in the True branch and sharpxrm_VerifyWithPostGridInternational in the False branch. Both actions take the same inputs. The designer shows "Showing 11 of 56" because the API Configuration input lists every column of that table. Only the ID field needs a value.

Input fields

A transaction log is written only when Save Transaction Logs is enabled on the API Configuration row.

Output values

Merge the result

Only one of the two actions runs, so a Compose named PostGrid result picks the output of whichever one did:

coalesce(outputs('Verify_with_PostGrid')?['body'], outputs('Verify_with_PostGrid_International')?['body'])

Later steps read fields from this compose, for example outputs('PostGrid_result')?['VerificationStatus'].

Decide whether to update the row

PostGrid has no rooftop indicator. The equivalent of a precise match is an address PostGrid confirms as deliverable. The example overwrites Address 1 only when:

• ResultFound is equal to Success, and
• VerificationStatus is Verified or Corrected.

In the True branch, Update a row (Contacts) maps the standardized components to the Address 1 columns. Each column keeps its current value when the output is empty, for example if(empty(outputs('PostGrid_result')?['County']), outputs('Get_contact')?['body/address1_county'], outputs('PostGrid_result')?['County']). Latitude and longitude are only written when PostGrid returned coordinates. The country is written as the ISO code (for example US). If you prefer to keep the country name, leave the country column out of the update.

In the False branch, a Compose records VerificationStatus, MissingComponents and VerificationDetails. A MissingSecondary result is a good trigger to ask the user for the missing unit: the rest of the returned address is already correct.

Example

Verifying 780 Greenwich St, New York, NY without a unit returns ResultFound = Success, VerificationStatus = MissingSecondary and MissingComponents = Suite identifier, with the full standardized address intact. The example flow does not overwrite the contact, and the run history shows which component to ask for.

Troubleshooting

Related articles

• Set up your PostGrid API Keys
• Understanding Address Confidence Levels
• Validate Addresses with Power Automate: Google Maps Geocoding (Unbound Action)