How to Evaluate an Integration Services Partner: 10 Questions to Ask Before You Sign

You are already live on Workday or Infor. The platform is configured, your tenant is in production, and your core modules are delivering measurable value. Now you need integrations. Your benefits carrier needs an 834 transaction file on a nightly schedule. Your third-party WMS needs to consume inventory BODs from Infor ION in real time. Your analytics platform needs a live feed of Workday HCM data via REST API. None of these happen without an integration partner, and choosing the wrong one has compounding consequences that outlast the initial project by years.

The bad news: every integration services firm you speak to will tell you they have deep platform expertise. The good news: the questions below are designed to cut through that quickly.

Workday alone reports over 300,000 integrations completed and nearly 900 million successful integration runs across its platform. That volume signals something important: the ecosystem is crowded, and not all participants are equally qualified. The 10 questions in this guide are written for buyers who already understand the platforms they run. They skip the basics and go straight to the technical and operational indicators that distinguish a capable partner from one who will become a liability three releases down the road.

Why This Decision Is More Complex Than It Looks

When you hire a project team to build integrations, you are not buying a deliverable. You are establishing a long-term technical dependency. Integrations connect your core platforms to adjacent systems, and those connections must survive platform updates, schema changes, personnel turnover, and evolving business requirements.

Workday releases major updates twice annually. Infor CloudSuite operates on a continuous delivery model with feature updates pushed on a rolling schedule. Every release is an opportunity for a poorly architected integration to break silently, corrupt data, or fail to comply with updated security policies. A partner who builds and exits leaves you managing that risk alone.

The questions below are structured to expose both technical capability and operational discipline. You need both.

Question 1: What Certifications Do You Hold, and Are They Current?

Certification validates that a partner’s developers have completed structured training against current platform documentation and testing standards. For Workday environments, ask whether the partner holds active credentials under the Workday Partner Programme, specifically including Workday Pro Integrations certification for developers who will be doing hands-on build work on your account.

The word “current” is load-bearing here. Workday certifications tied to release cycles that are two or more versions old may reflect integration patterns that have since been superseded. Specifically, partners whose developers were certified primarily against SOAP-based web service patterns may lack hands-on depth with the REST API framework and Workday Orchestrate, both of which represent the current direction of Workday’s integration architecture.

For Infor environments, ask about Infor Alliance Partner status and which CloudSuite modules the partner’s certified resources have worked with directly in production. Infor ION, the middleware layer underpinning most Infor integrations, has its own certification track. A partner who cannot name the ION components their team has deployed, including ION Connect, ION Mapper, ION Workflow, and ION Desk, has surface-level exposure at best.

Question 2: How Do You Handle Platform Updates and Breaking Changes?

This question consistently separates experienced integration partners from ones who are still learning on your time. Workday’s bi-annual release cycle and Infor CloudSuite’s continuous delivery model both introduce API changes, schema updates, and occasionally deprecated endpoints. Without a defined process, breaking changes reach production before anyone notices.

Ask the partner to walk through their exact protocol when a Workday release introduces a change to an API endpoint or WSDL definition that affects a deployed integration. A credible answer includes a pre-release review of Workday’s update documentation, a regression testing pass against affected integrations in a sandbox or implementation tenant before the release reaches production, and a documented SLA for restoring integration functionality if a regression is identified post-release.

For Workday EIB integrations specifically, breaking changes often surface in calculated field logic, XSLT transformations, or reference ID mappings rather than in the API layer itself. A partner who only monitors API changelogs and does not run full regression tests on EIB templates before each release is missing a significant failure surface. The most common EIB failure patterns in production are directly tied to upstream schema changes that a structured testing process would catch in the sandbox environment before they propagate to live payroll or benefits feeds.

For Infor ION environments, ask how the partner handles BOD schema versioning across updates. Infor ION uses Business Object Documents (BODs) as the standard integration interface, structured as XML messages based on the OAGIS schema standard. When Infor updates the BOD schema for a particular document type, any ION Mapper transformation that references the prior schema structure will produce malformed output. That failure mode is often silent until a downstream system rejects the payload.

Question 3: What Integration Architecture Do You Recommend for My Use Case, and Why?

This is the most technically revealing question on the list. A partner who recommends the same architecture for every client is operating from a template, not from an understanding of your system landscape and operational requirements.

In Workday environments, the integration toolset spans several distinct patterns, and the right choice depends on data volume, acceptable latency, transformation complexity, and your team’s ongoing support capacity:

Enterprise Interface Builder (EIB) is appropriate for file-based inbound and outbound loads with modest transformation requirements. EIBs follow a three-step pattern: Get Data, Transform, Deliver. They support XSLT transformations, PGP encryption for secure file delivery, calculated field logic for inline data manipulation, and scheduling parameters for automated execution. They are not appropriate for real-time use cases or for integrations requiring conditional orchestration logic across multiple systems.

Workday Studio is an Eclipse-based development environment designed for complex integrations that require custom Java logic, multi-step orchestration, try-catch error handling, conditional routing based on upstream API responses, and calls to external REST or SOAP endpoints. Studio integrations support modular assembly design, which enables reuse of transformation components across multiple integration flows. Studio has a 10-hour execution limit per event, which becomes relevant for high-volume batch operations.

Workday REST API with OAuth 2.0 provides the most current and performant pattern for real-time system-to-system data access. The API organises endpoints into logical functional domains: the HCM API for worker lifecycle operations including hire, transfer, and terminate events; the Payroll API for pay run data, deductions, and tax information; the Absence Management API for leave balance synchronisation; and the Financial Management API for journal entries, supplier invoices, and procurement data. REST responses return JSON-structured payloads, which are more lightweight than the SOAP XML equivalents and more compatible with modern downstream systems. For a production-level breakdown of the REST API architecture and its authentication patterns, the Workday REST API integration guide covers endpoint organisation, OAuth token management, delta processing, and rate limit management in detail.

Workday Orchestrate is the most significant recent addition to the integration toolset. According to Workday’s Integration Cloud product documentation, Orchestrate is a low-code visual builder that supports event-driven integrations, batch data processing, built-in retry logic, and real-time operational monitoring — at no additional cost to existing Workday subscribers. Early adoption data shows 30 to 50 percent reductions in implementation time compared to equivalent Studio-based development, and boomerang integrations previously running in four to five seconds via Studio have seen nearly 50 percent reductions in processing time when migrated to Orchestrate. A partner who is still defaulting to Studio for new event-driven builds in 2025 without a specific technical justification is not current.

For Infor environments, ask the partner to explain their approach to the ION integration layer specifically. According to the Infor ION Development Guide, the preferred integration pattern is the Infor Application Connector, which is decoupled, event-driven, and uses the inbox/outbox BOD model to avoid hard dependencies between systems. ION supports over 200 pre-built BOD types covering common business transactions. The platform also exposes an IMS (ION Messaging Service) connection point for REST/JSON-based integration with external systems that lack native ION support. A partner who defaults to the File Connector for all Infor integrations — which introduces the risk of duplicate message delivery on timeout and lacks the inbox/outbox reliability guarantees — is using a fallback pattern as a default, which is a signal worth probing.

For more on event-driven integration patterns within Infor LN specifically, the Infor LN event management technical overview covers the configuration steps and architectural dependencies that govern how LN publishes business events to ION.

Question 4: How Do You Configure Integration System Users and Manage Authentication?

This question surfaces security maturity. It requires practical knowledge of Workday tenant administration and is not answerable from documentation alone.

In Workday, each integration requires a dedicated Integration System User (ISU). An ISU is a service account created specifically for the integration, separate from any human user identity. A properly configured ISU has Session Timeout Minutes set to 0 to prevent timeout during long-running operations, the Do Not Allow UI Sessions checkbox enabled to restrict interactive logins, and the account added to the password expiration exemption list via the Maintain Password Rules task to ensure the integration does not break when the standard password rotation policy triggers.

Each ISU should be assigned to a dedicated integration system security group with domain-level permissions scoped precisely to what the integration requires. Workday offers two security group types: Integration System Security Group (Unconstrained), which grants access to all data instances secured by the group, and Integration System Security Group (Constrained), which limits access to a subset of instances based on configurable context. Sharing an ISU or a security group across multiple integrations is a material audit risk and a compliance concern in any regulated environment.

For REST API-based integrations, ask the partner how they handle OAuth 2.0 client registration. Each OAuth client registered in Workday requires a defined scope that determines which API resources the client can access. Scope-based access control under least-privilege principles means an OAuth client used for Absence Management data synchronisation should not carry scopes that permit access to Payroll or Financial Management endpoints. Ask whether the partner follows this principle consistently, or whether they register broadly-scoped clients for convenience.

For Infor ION environments, ask how the partner configures ION’s OAuth 2.0 authentication for external REST connections via the IMS connector, and how they enforce role-based access control within ION Desk for managing connection point permissions.

Question 5: What Is Your Post-Go-Live Support Model?

Integration projects are routinely over-resourced during build and under-resourced after go-live. The senior developer who understands every assembly in your Studio integration rolls off the project, and the support tier that remains lacks the context to diagnose production incidents quickly.

Ask the partner to provide their support tier structure in writing, with specific SLAs attached to each tier. A P1 incident affecting a live payroll feed or a benefits carrier connection should carry a response SLA measured in minutes, not business hours. Ask who the named escalation resource is for your account, what their notice period is if they leave the partner organisation, and what the knowledge transfer protocol is when integration ownership changes hands internally.

Managed integration services structured as a retainer engagement, rather than a project with a defined end date, produce materially different support outcomes. Retainer-based arrangements incentivise proactive monitoring, version compatibility testing before each Workday release, and documentation maintenance. Project-based arrangements incentivise delivery speed, which means support infrastructure is often the first thing descoped when timelines compress.

Question 6: Can You Demonstrate Case Studies Specific to My Integration Pattern?

Generic case studies describe outcomes. Technical case studies describe the problem, the constraints, the architecture choices made, and the tradeoffs accepted. The latter are what you need.

If your primary integration requirement is a Workday-to-benefits-carrier connection using an SFTP-delivered 834 transaction file, ask the partner to walk through how they have implemented this pattern previously. What XSLT transformation logic did they use to map Workday’s worker benefit elections to the 834 schema? How did they handle dependent coverage records with multiple relationship type codes? What was their retry strategy when the carrier SFTP server was unreachable?

If you are running Infor LN and need to connect to a third-party CRM via ION, ask whether the partner has mapped LN business events to the relevant BOD types in production, configured ION Mapper for the required schema transformation, and validated the connection through ION Desk’s flow monitoring. The specificity of their answer tells you whether they are describing a project they ran or a project they read about.

Question 7: How Do You Build and Surface Integration Monitoring?

Silent failure is the most expensive integration failure mode. A Studio integration that returns a success status in Workday’s Process Monitor while failing to deliver its output file to the downstream system will not trigger any alert unless monitoring is explicitly configured to catch it.

Ask the partner how they distinguish between a Workday-level success and an end-to-end success in their monitoring architecture. In Workday Studio, integration events can complete at the Workday layer while failing silently at the delivery layer: the file was generated but the SFTP connection to the receiving system timed out, or the HTTP call to the external REST endpoint returned a 4xx response after the Studio event had already logged completion.

EIB integrations carry a different failure profile. Because EIBs are frequently triggered manually by business users rather than on a system schedule, the failure mode is often a user-initiated load that fails due to a validation error and is silently abandoned rather than escalated. Ask whether the partner configures automated email alerting on EIB failure events and whether they implement pre-validation reports to catch data quality issues before the EIB executes.

For Workday Orchestrate deployments, the platform provides comprehensive real-time monitoring with status and performance visibility built into the operational control layer. For ION environments, ION Console provides real-time visibility into BOD flow status, and partners should be configuring threshold-based alerts for failed BOD transfers and workflow exceptions through ION Desk.

A well-built integration monitoring framework does not require a human to check dashboards. It surfaces anomalies proactively and routes alerts to the right team within the SLA window.

Question 8: What Does Your Discovery and Scoping Process Look Like?

Fixed-price integration estimates produced after a one-hour discovery call are a commercial risk signal. Integration scope is determined by the number of data objects in scope, the transformation complexity at each mapping layer, the number of dependent downstream systems, the error handling requirements for each failure mode, and the volume and frequency of data exchange.

A rigorous discovery engagement for a Workday REST API integration includes: a review of the target system’s data model to identify field mapping gaps against Workday’s object structure, which uses unique object references and versioned endpoints rather than flat identifiers; a latency requirements assessment to determine whether the pattern should be event-driven via Workday Orchestrate, real-time request-response via REST, or scheduled batch via Studio or EIB; an authentication and security design session covering ISU configuration, OAuth scope definition, and credential management procedures; and a written requirements document against which the integration design will be validated before development begins.

The custom integration development engagement model that credible partners follow includes a formal design phase that translates discovery findings into a detailed architecture document and a project roadmap before a single line of code is written. Partners who skip this step routinely deliver integrations that require significant rework to handle edge cases their initial estimate did not account for.

Question 9: How Do You Architect Error Handling and Recovery?

Every integration will encounter errors. The question is whether those errors are caught, classified, logged, escalated, and resolved before they propagate into downstream systems or corrupt production data.

In Workday Studio, robust error handling is implemented through try-catch constructs at each step of the orchestration flow. Catch blocks should log the full stack trace to the integration event log, send automated email alerts to a defined distribution list, and route the failed payload to a persistent error queue for manual review or automated resubmission. Conditional routing components handle retryable errors differently from terminal errors: a 401 Unauthorized response from an external REST endpoint should trigger a token refresh flow and retry, while a 400 Bad Request indicating a data validation failure should route directly to the error queue for human intervention.

For batch integrations running via EIB, partial failure handling is critical. An EIB processing a bulk compensation load should not silently drop records that fail validation while successfully loading the remainder. Ask the partner how they implement per-record error logging in EIB integrations and how they surface the error report to the operational team.

For Infor ION environments, the publish-and-subscribe architecture provides a degree of native fault isolation: if a subscribing application fails to process an inbound BOD, the failure does not affect other subscribers on the same connection point. However, this isolation does not substitute for explicit retry configuration and failure alerting within the ION Workflow layer.

Ask the partner to define what constitutes a retryable error versus a terminal error in their standard integration architecture, and ask for documentation of how that classification is implemented in production systems they currently support.

Question 10: How Do You Align With Our Integration Roadmap as Our Environment Scales?

The integrations you need today are not the integrations you will need in 24 months. New SaaS tools enter your ecosystem, legacy systems get retired, modules get added to your core platform, and regulatory requirements change the data your carriers and partners need from you.

A capable partner maintains active awareness of the platform vendor’s product roadmap and proactively maps that roadmap against your current integration inventory. The migration from Workday Studio to Workday Orchestrate is a relevant current example. Organisations whose partners identified Studio integrations that meet the architectural profile for Orchestrate migration, assessed the implementation effort, and recommended a phased migration plan ahead of general availability are in a structurally better position than organisations whose partners had no proactive input on the transition.

For a technical walkthrough of what Workday Orchestrate-based integration architecture looks like in a live onboarding automation context, the Workday Orchestrate implementation guide covers event trigger configuration, cross-system connector design, and the operational monitoring setup that supports production deployments.

For Infor environments, ask how the partner stays current with Infor ION feature releases, including updates to the ION API management layer that enable external partners and mobile applications to interact with your business data through ION-governed APIs. A partner who is not tracking the ION roadmap cannot give you informed advice about which integration patterns you should be investing in versus which ones you should be planning to deprecate.

What to Do With the Answers

These ten questions produce two categories of signal. Technical signals tell you whether the partner’s developers can build integrations that are architecturally sound, secure by configuration, and resilient under failure conditions. Operational signals tell you whether the partner has the processes to support those integrations reliably over a multi-year horizon.

A partner can have excellent technical depth and poor operational discipline. A partner can have mature support processes and shallow platform knowledge. Both combinations produce problems. You need evidence of both, applied consistently, before you commit to a contract.

Before any statement of work is signed, ask the partner to provide written answers to each question as applied to your specific environment and the integrations in scope. Any partner who is unwilling to document their answers before contract execution is communicating something meaningful about how they will behave after it.

For organisations that need post-deployment integration support and troubleshooting as a structured, SLA-governed service rather than an ad-hoc engagement, defining the scope and terms of that support before the initial build begins is the most important commercial decision in the engagement. The integration architecture your partner builds determines how easy or difficult that support will be for the next five years.

Treat integration infrastructure with the same rigour you apply to platform procurement. The decision is worth the diligence.

Sama Integrations works with enterprises running Workday and Infor to design, build, and support integration architectures that are technically sound, operationally reliable, and aligned with platform roadmaps. Contact the team to discuss your integration requirements.