Set Integration Acceptance Criteria With Both Technical and Lab Owners

An automation engineer walks into your review with a finished design drawing and asks you to approve the integration on the spot. You are a field application scientist, not the systems owner, and you cannot clear a workflow that touches the customer's laboratory without the people who run that laboratory every day. The drawing looks complete, the request feels urgent, and saying yes would be the fast answer. Saying yes anyway is how integrations pass a technical review and then fail once real samples and real exceptions hit the lab, because nobody asked the daily user what she needed to see first.

Why this conversation goes wrong

A design drawing shows intended data flow. It does not show what happens when a sample identifier is malformed, when an instrument times out mid run, or when two systems disagree about a result format. Engineers are usually judged on shipping the interface, not on whether the lab accepts it, so they treat the drawing as the finish line. The scientist who actually runs the workflow every day is often absent from the meeting entirely, because nobody thought to invite her to a technical design review.

You feel pressure from both sides. The account wants to go live, the engineer wants a decision, and pausing the conversation looks like you are slowing things down for no reason. If you approve anything that sounds like a green light, that answer gets repeated later as proof that the lab signed off, even though the lab never saw the plan. That is the actual failure mode here, not a bad drawing but an approval that traveled further than you meant it to.

How to prepare before the conversation

Before you sit down with the engineer, map the proposed connection on paper. List every system involved, the inputs and outputs at each step, the handoffs between people and machines, and how exceptions get handled when something does not match expectations. For each piece, write down who owns it. If you cannot name the owner of a handoff, that is a gap you need to raise, not one you can fill in yourself.

Find out who the daily user actually is. It is rarely the account contact and rarely the person who requested the integration. It is the scientist standing at the bench who will notice immediately if sample identifiers stop matching or if a report lands in the wrong format. Pull whatever interface specifications your organization has already approved for this kind of connection, and check the drawing against them line by line rather than accepting the engineer's summary of what it does.

Decide ahead of time what you can actually approve. You can compare a drawing to an approved specification and flag mismatches. You cannot approve the customer's production use of that integration, and you cannot validate it on their behalf. Knowing that line before you walk in keeps you from being talked past it in the moment.

What to say when the engineer wants a signature

The engineer opens with the ask you expected. "Can you approve this integration based on the design we put together? We'd like to move forward this week."

You answer without giving away more than you actually own. "I can compare your drawing against the approved interface specification, and I'm glad to do that today. But I can't approve the integration for the lab. Has the scientist who runs this workflow every day reviewed the acceptance evidence with you?"

The engineer admits she has not. "Honestly, no. We built this off the interface spec and assumed the workflow would follow."

You propose the next concrete step instead of leaving it open. "Let's get her in a session with both of us so we can map the sample identifiers and walk through what happens on the exception paths. That's the evidence she needs before anyone treats this as accepted."

The engineer raises the schedule. "We were told this needed to go live next week."

You hold the line while still moving things forward. "Then let's book that session in the next two days so it doesn't become the thing that delays you. I'd rather find a mismatch now than after go live."

That last line matters. You are not blocking the project, you are protecting it from failing in a way that costs everyone more time later.

Mistakes to avoid

A few habits turn this conversation into a real problem instead of a manageable one.

1. Treating a drawing as proof of behavior. A diagram tells you what someone intended to build, not what the system does with a malformed sample identifier or a dropped connection.

2. Approving something under schedule pressure because refusing feels like you are the obstacle. The schedule pressure is real, but your approval does not make the integration work, it just makes you responsible if it does not.

3. Leaving the daily lab user out of the room. If the person who will use the workflow every day was not part of defining acceptance, the acceptance is not real, no matter how many technical reviewers signed off.

4. Accepting a vague promise to validate later without naming what that validation looks like or who owns it. "We'll test it after go live" is not a plan, it is a way of skipping the plan.

5. Speaking for the customer's organization because it seems faster than waiting for their answer. You can review a specification. You cannot decide, for the customer, that their lab accepts a workflow.

How to practice and score this conversation

This kind of exchange is easy to get wrong the first time you face it, because the pressure to just say yes is stronger in the room than it sounds on paper. Practicing it before it happens for real is worth the time. Take a simple interface diagram, hand it to a colleague or trainee playing the engineer role, and have them push for immediate approval. Ask the trainee to respond by naming three specific acceptance observations the lab owner would need before anyone calls the integration accepted.

A manager scoring that practice run should look for a few specific things rather than a general impression. Did the trainee separate what they can review, the drawing against a specification, from what they cannot approve, customer acceptance. Did they name the actual daily user rather than accepting the account contact as a stand in. Did they secure a concrete next step, a joint session with a defined agenda, instead of a vague promise to follow up. And did they hold that position once the engineer raised a deadline, without either caving or becoming unhelpful about the timeline.

You can rehearse this scenario and others close to it among the Biotechnology practice conversationswhich cover the kinds of exchanges field application scientists run into with technical teams, lab staff, and account contacts who all want something different from you at once. If you want to see how this same discipline of routing a decision to the right owner plays out in a different setting, the post on how to Update an Invoice Remittance Contact Through the Right Review covers a similar problem with billing changes. And when the daily lab user you need in the room has just changed, the plan in Create a Support Plan When a Laboratory Champion Changes Roles walks through how to rebuild that relationship before it becomes a gap in your next integration review.

The engineer's drawing is a starting point, not a decision. Your job is to turn the request into a joint validation plan that includes the person who will actually live with the workflow, and to say clearly what you can and cannot approve along the way.