Who is this post for?

This post is primarily for product teams looking to integrate their SaaS products with the Google and Microsoft productivity suites. Our team went through quite a bit of toil. I am writing this to spare other product managers some of that pain...or at least help them understand what they are getting themselves into.

The saga begins with us spending months avoiding a roughly $4,500 security assessment. Google wanted us to complete the assessment through a third-party auditor before it would approve the restricted OAuth scopes our Google Drive integration needed. We had a launch to get out, and Google's Picker UI appeared to offer a simpler route. We took it.

The Picker could show files belonging to the person logged into Google, but our product had a meaningful separation between the administrator configuring an integration and the end user authenticating with Google. It also could not support the full set of programmatic file operations the product needed. We discovered those limitations after customers were already using the integration.

The cheap shortcut cost us months. We eventually completed the assessment anyway, rebuilt the integration, and faced the much uglier problem of moving people from an OAuth connection they had already authorized to a new one they had not.

I was fully on board with this shortcut at the time. We were moving quickly, the workaround looked viable, and I treated certification as administrative friction surrounding the integration. That was the mistake.

Certification, scopes, app registrations, tenant structure, account ownership, and customer authorization are all part of the integration architecture. I wish I had understood that more deeply at the beginning, because a bad decision in any one of those areas becomes painful to unwind after launch.

Start With the Authorization Model, Not the Happy Path

Most early integration demos answer a narrow question: can we connect the systems and make the intended action happen? Necessary, obviously. Nowhere near enough.

Before approving an integration approach, map every role that will touch it:

  • Who configures the integration?
  • Who authenticates with the external service?
  • Can an administrator configure it on behalf of another user?
  • Must it perform background operations when nobody is present?
  • What happens when the authenticating employee leaves?

Our Google shortcut passed the basic demo and failed the real operating model. The person using the Picker had to be the person authenticated in the browser. Once we tested the builder/admin separation honestly, the approach fell apart.

Test the least convenient legitimate user journey first: the customer administrator, the end user, the person with minimum permissions, and the background job that needs to keep working next Tuesday when nobody is staring at the browser. That is where shortcuts tend to fall apart.

Treat OAuth Scopes as a Product Roadmap Decision

OAuth scopes can look like an implementation detail. In practice, they define what your integration can become.

If an integration launches with one set of scopes and later needs broader access, customers may need to consent again. Depending on the platform and how your integration is deployed, you may need a new app registration or integration instance. You cannot quietly consent on a customer's behalf, and you should not build a migration plan that assumes customers will eagerly reauthenticate because you sent a nice email.

Before submitting an app for verification, build a scope roadmap:

  1. Document the actions required for the first release.
  2. Identify the capabilities you reasonably expect over the next two or three years.
  3. Determine which future capabilities require new scopes.
  4. Ask whether the initial certification path supports those scopes.
  5. Test the full scope set in a development environment.

Do not ask for every available permission. Ask for the broadest set you can defend from a real product roadmap, because adding scopes later can mean asking every customer to reauthenticate.

Google: Do the Painful Thing First

For our use case, Google's restricted scopes required a Cloud Application Security Assessment, or CASA. We eventually used TAC Security and pursued the broadest assessment path available to us. The process included a security questionnaire, dynamic scanning, static source review, remediation work, and a Letter of Validation.

Some of it felt like security theater. Some of it was useful. The dynamic scan found endpoints accepting HTTP where they should have required HTTPS. The assessment took several weeks, and the final validation letter required more chasing than I expected.

Google support did not behave like a continuous account team. Each interaction could involve a different reviewer with little apparent context from the prior exchange. We repeatedly received the default suggestion to use the Picker UI, even though we had already determined that Picker could not support our architecture. A scope correction sent us back through earlier steps.

Knowing what I know now, this is the order I would follow:

  1. Decide whether the integration genuinely requires restricted scopes.
  2. If it does, begin the security-assessment process immediately.
  3. Validate role separation and background operations before accepting a lighter UI-based alternative.
  4. Test all anticipated scopes in a separate project.
  5. Submit validation evidence and a concise technical justification for every scope.
  6. Put renewal ownership on a team-managed alias and calendar.

Google's current documentation says apps using restricted scopes require annual security reassessment. That makes renewal ownership an operational product requirement, not a compliance footnote. If the renewal notice goes to an employee who has left, the first person to tell you the integration stopped working may be a customer.

Also, older apps in your product portfolio may have been approved under policies or product paths that no longer exist. "We already have a Google integration" does not mean "we know how to launch one today."

Microsoft: Get Your House in Order

Our Microsoft work was difficult for a different reason. We were primarily a Google Workspace company with years of accumulated Microsoft odds and ends: production tenants, test tenants, old app registrations, personal test accounts, and unclear ownership. We were establishing a clean Microsoft foundation while building customer-facing integrations.

That is a bad time to discover your Microsoft estate.

Before building a customer-facing Microsoft integration, work with your IT team to inventory:

  • Every Entra tenant, verified domain, and app registration
  • Every development and test environment
  • Every Partner Center account and Partner ID
  • Every owner of a subscription, app, or renewal
  • Every legacy customer connection that cannot move without reauthorization

Then decide which environments are authoritative.

For us, the sustainable pattern was one production tenant on the product's verified domain and one development/demo/test tenant. Scope experimentation happened in test; known-good configurations moved to production.

The temptation is to create another Microsoft environment whenever an existing one is confusing. Resist it. Every new environment becomes another thing someone must own, secure, document, pay for, and eventually explain during an incident.

Microsoft publisher verification crossed boundaries between Entra, Partner Center, identity-provider-managed permissions, and human identity verification. Some actions needed elevated roles the team did not ordinarily grant. None of these issues was dramatic alone. Together, and with slow support cycles, they stretched into weeks...and then months.

This is the kind of work a PM can accidentally describe as "get the Microsoft app certified," as though it were one ticket. It is usually a small program involving product, engineering, IT, security, compliance, and whoever controls DNS. Plan it that way.

What Do I Actually Get When I Buy an iPaaS?

After we built several integrations, wrestled through certification, and wrote custom components when the platform's connectors fell short, I bluntly asked two people closest to the work:

What do I actually get when I buy an iPaaS?

The short answer: You buy credential management, hosted execution, scalability, and adapter lifecycle management. If the platform's prebuilt connectors cover your needs, you also buy development speed and insulation from many third-party API changes. If you build most connectors yourself, the iPaaS increasingly becomes expensive integration infrastructure.

The biggest surprise was what we did not buy: expertise in getting third-party integrations certified.

Our team assumed that an iPaaS vendor powering Google and Microsoft integrations would be a rich source of experience with their certification processes. We were shocked by how little practical guidance the vendor could provide when we hit those problems. In retrospect, the boundary is clearer than I understood it at the time. The iPaaS powers the integration, but we are the app publisher asking Google and Microsoft to trust us with customer data. Certification is our process, our evidence, and our problem to solve.

The vendor may help around the edges, but its support cannot be the plan. I wish I had understood that much sooner.

Managing OAuth credentials, executions, scaling, monitoring, and connector compatibility is real work. But the value depends on how much of the platform you can actually use.

If a prebuilt connector supports the operations and scopes your product needs, the platform may save substantial engineering and maintenance effort. If the connector lacks a required capability and the vendor tells you to use a raw REST request, you are now writing and maintaining custom integration code on somebody else's infrastructure. You may still benefit from its credential management and hosted execution, but you are no longer receiving much connector lifecycle management for that integration.

Do not evaluate an iPaaS by the logos in its connector catalog. Evaluate it against your roadmap and the specific operations each integration requires. It will not own your authorization model, understand every role boundary, or make certification disappear. We learned all three of those the annoying way.

The decision is rarely as clean as "buy an iPaaS" or "build integrations ourselves." Ask:

  • Which connectors actually cover our roadmap?
  • What does the platform operate when we write custom components?
  • How are credentials stored, rotated, and migrated?
  • What is the pricing unit: executions, connections, customer instances, or something else?
  • How would customers reauthorize if we left the platform?

An iPaaS can reduce engineering work. It cannot remove the product consequences of OAuth.

The Migration Is the Product Problem

Technical teams can usually rebuild an integration. The harder problem is the customer connection.

OAuth consent belongs to the customer. Credentials cannot simply be reassigned to a different app registration or integration instance because your architecture changed. If customers must reauthenticate, your migration is now a product adoption campaign with support load, communication risk, drop-off, and possible churn.

A workaround that saves four weeks before launch but creates a future forced migration may be a terrible trade. A more expensive certification path that preserves the right authorization model may be the fastest path when measured across the life of the product.

Integration architecture has a ratchet. Once customers authorize and depend on a connection, some early decisions only move in one direction.

A Pre-Build Checklist for Product Managers

Before your team writes the production integration, get explicit answers to these questions.

Product and roles

  • Who configures, authenticates, uses, and owns the integration?
  • Must it operate in the background?
  • What happens when the authenticating user leaves?

Scopes and certification

  • Which scopes are required now and within the roadmap horizon?
  • Which are sensitive or restricted?
  • What changes would trigger re-verification or customer re-consent?

Environments and ownership

  • Which tenant, cloud project, and app registration are authoritative?
  • Is the production app on the correct verified product domain?
  • Are all owner and renewal contacts team-managed aliases?

Operations and vendors

  • What does the vendor own, and what remains your responsibility?
  • How long do support-dependent steps take in practice?

Migration

  • Can existing customer authorizations move to a replacement app?
  • Can you maintain two versions during migration?
  • What happens to customers who never act?

If the team cannot answer these questions, it is not ready to estimate the integration.

Budget for the Bureaucracy You Actually Have

The timelines below came from one team's experience, not a universal service-level agreement:

  • A Google security assessment and app verification took roughly five to six weeks once we followed the correct path.
  • Establishing a clean Microsoft environment and verified publisher setup took several weeks.
  • Documenting appropriate Microsoft permissions took one to two months of iteration.
  • Support-dependent steps routinely took far longer than the underlying technical work.

Rules and portals change, so verify the current process before planning. Then budget two to four times your optimistic estimate for critical-path work controlled by a large platform's support or verification organization.

And start those steps before the integration is "done." Waiting until launch readiness to begin certification is how a product ends up complete, unusable, and increasingly discussed in uncomfortable status meetings.

What I Would Do Differently

If I were starting the same work again, I would begin with a two-page integration authorization brief before approving implementation.

It would name the roles, scopes, certification path, authoritative environments, owner aliases, vendor responsibilities, renewal process, and reauthorization risks. Engineering, IT, security, and product would review it together. Any shortcut would need to explain how customers get off it later.

Then I would ask the team to attack the plan:

Where does role separation break? Which future scope forces re-consent? Which account belongs to a real person who may leave? Which environment does nobody fully understand? Which part are we assuming the iPaaS handles because we have not asked?

That work will feel slow when everyone wants to move quickly. It is still faster than rebuilding the integration and asking every customer to authorize it again.