Lana M.

Quick update on Verirow! 😊 I've been working on the feedback from this discussion, and the first pilot is now ready. I started with a small Salesforce → NetSuite reconciliation example using sample data, as Dheeraj suggested. It includes configurable checks and four scenarios: matching records, missing records, value mismatches, and records still within the allowed sync-delay window. The goal is to catch discrepancies even when an integration reports success, without having to recreate the entire integration logic. Dheeraj has kindly agreed to be one of the first testers, so I'm looking forward to seeing what works and what needs improving. Thanks again for all the feedback! I'll share what we learn from the pilot.

Thank you so much, Dheeraj. This is exactly the kind of feedback I was hoping for. Your point about not having to recreate the integration logic in a separate tool is especially important. I hadn't looked at it quite that way. I agree that starting with one specific integration makes more sense than trying to support every possible workflow at once. Since you mentioned NetSuite and Salesforce earlier, do you think that would be a useful first case to explore for independent reconciliation? I really appreciate the time you've taken to explain all of this. It's helping me understand what the product actually needs to do.

Thanks, Dheeraj! I really appreciate you sharing all of this. Can I ask you one last question? If you had a tool that independently checked source and destination data after every sync, what would it need to do for you or your team to actually use it? What features would matter most? And what would make it worth adding to your existing workflow instead of relying on integration logs and manual checks? I'm trying to understand what engineers actually need before deciding what to build next. And thank you so much for your time. This has been really valuable to me!

Thanks for sharing the example, Dheeraj! It's really useful to see how your team handles this. I can see that your integration already catches failed records and reports why they failed. What I'm interested in is what happens when the integration reports success, but the data in the destination is still different from the source. For example, all 10,000 records arrive, but some field values are incorrect, or duplicates appear without triggering an integration error. Do you have a separate process to catch those cases, or do you rely on the integration reports? This is the kind of gap I'm trying to understand with Verirow.

Thanks, Dheeraj, That makes sense! Here's a simple example: an integration moves 10,000 customer records from one system to another. The integration reports success, but the destination only has 9,999 records. Verirow compares both sides and identifies the missing record. It can also flag different values and duplicates. The idea is to catch these issues before someone from the business has to report them. The integration team can then investigate the cause using their existing logs and tools. Your explanation of how your team handles discrepancies is really useful. One thing I'm curious about: do you currently run any checks after a successful integration, or do you usually find out about issues when the business reports them?

Thanks, dheeraj k.! This is really helpful. Right now, Verirow focuses on identifying the gaps, not automatically fixing the integration. It compares source and target data and shows missing records, differences, and duplicates. My goal isn't to create a product and then look for a problem it can solve. I want to solve a problem businesses already deal with. When money, customer records, or critical business data are involved, even a small sync error can have real consequences for someone. I want teams to have more confidence that their data is actually correct, not just that a sync completed successfully. I'm exploring what should come next, especially how to make those results useful when investigating the root cause. When you find a mismatch, do you usually start with the integration logs or check the source and target records first?