Before an automation or AI solution goes live, it needs to be tested from two different angles.
Functional testing checks whether the solution does what the business needs: does the workflow trigger correctly, does the chatbot answer the right question, does the report contain the right figures?
Data validation testing checks whether the underlying data is handled correctly: are formats accepted or rejected as expected, are missing fields flagged, are duplicate records caught before they cause problems downstream (Tricentis, 2025).
Both are needed. A solution can pass every functional test and still fail in production if it has never been tested against messy, incomplete or unexpected real-world data. Testing should always use a representative sample of genuine data, not just clean, ideal examples, and should include scenarios where a connected system is slow, unavailable or returns an error.
Most integration failures share the same root causes. Data mapping is often underestimated: two systems rarely store the same information in the same format, so fields, statuses and validation rules must be carefully matched before data can flow between them. Application programming interfaces (APIs) are not all equal; some are well documented and stable, while others are restrictive, poorly documented or prone to unannounced changes, and this should be checked before an integration is built rather than discovered afterwards. Connecting systems directly to each other without an overall design also becomes unmanageable as more systems are added, since a single change can break several connections at once. Finally, an integration with no named owner tends to degrade silently over time as the connected systems change, so problems are often only noticed once data has already been lost or duplicated (Clarke, 2026).
The platform on which a solution is built also shapes what is possible.
Cloud platforms, such as Microsoft Azure or Google Cloud Platform, provide on-demand access to shared computing resources that can scale up or down and are managed largely by the provider (Mell and Grance, 2011). This offers flexibility and lower upfront cost, but it also means depending on the provider’s infrastructure, reliability and security arrangements, and can raise questions about where data is stored and processed.
On-premises systems give an organisation direct control over its own infrastructure and data, at the cost of higher maintenance and slower scaling.
Third-party platforms, such as Zapier, Make or Notion, add further constraints of their own: limits on how many actions can run, restrictions on what data can be exported, and dependence on a vendor’s roadmap and pricing decisions.
Software as a Service tools are quick to adopt but offer little control over the underlying infrastructure, while Platform as a Service options, such as Azure AI Foundry or AWS SageMaker, allow more custom development but still inherit the limits of the provider beneath them. Public sector guidance recommends weighing these trade-offs, including vendor lock-in, before committing to a platform (GOV.UK, 2023).
Testing, integration risk, and platform constraints are connected. A platform’s limits determine what can realistically be tested and integrated, and thorough testing is the only reliable way to discover those limits before they affect real users (Erl and Monroy, 2023).
Action Point
Before choosing or building an automation solution, list the platform’s known constraints such as cost, scalability, security, compliance, and vendor dependency. Plan functional and data validation testing using real data and realistic failure scenarios, and name an owner responsible for monitoring the integration once it is live.