How to Verify Data After a Boomi Process Run

A successful Boomi process does not automatically prove that every source record reached the target correctly. To verify the result, compare source and target data after the process finishes and classify missing records, field mismatches, and duplicates.

A Boomi process can complete successfully while the data on the target side is still incomplete or incorrect.

Process success tells you that the integration ran. It does not automatically prove that every expected record arrived with the correct values.

That is where post-sync verification becomes useful.

Process success and data success are different things

An integration can finish without throwing an execution error and still leave behind data issues such as:

• records that never reached the target
• field values that do not match the source
• duplicate records created during processing
• partial updates where only some expected changes were applied

Traditional process monitoring is important, but it answers a different question: did the process run?

Post-sync verification asks: did the data arrive correctly?

Use source-to-target reconciliation

The most direct way to verify a completed sync is to compare the source dataset with the target dataset after the process finishes.

A useful reconciliation workflow needs a stable key that identifies the same record in both systems, plus the fields that should be compared.

Source → Target → Match records → Compare fields → Classify issues → Review result

Missing

A record exists in the source but cannot be found in the target.

Different

The record exists in both systems, but one or more selected values do not match.

Duplicate

The same key appears more than once where a single matching record was expected.

Verify after the integration, not instead of it

A reconciliation layer does not need to replace the existing Boomi process.

The integration can continue moving data normally. Verification runs after the process and independently checks the result.

This keeps responsibilities separate:

Boomi moves the data. Verification proves what arrived.

Make the check repeatable

For recurring integrations, the verification setup should not have to be rebuilt after every run.

A saved check can define the source, target, matching key, compared fields and connection configuration once. The same verification can then be triggered again after future process runs.

Keeping run history is also useful because it creates a record of what was checked, how many records were processed, whether issues were found and when the verification happened.

Where Verirow fits

Verirow is an independent post-sync verification platform built around this workflow.

After a Boomi process runs, Verirow compares source and target data and classifies the result as OK, Missing, Different or Duplicate.

It is not another integration layer and it does not replace the Boomi process. The purpose is to add an independent verification step after the sync.

See the full Verirow case study for the product architecture, reconciliation engine, run history, security model and trigger workflow.

Checks can be run manually or triggered from an integration workflow, and completed runs remain available in History with their status, issue count, trigger and duration.

The core principle

A green process status is useful operational information.

But when the real requirement is data correctness, the final check needs to happen at the data level.

Run the integration. Then verify the result.

Try Verirow for Boomi

Verirow is built for repeatable post-sync verification after Boomi processes. Configure the source and target once, trigger the check after an integration run, and keep the reconciliation result in history.