Microsoft 365 integration: Which Path to Choose? Pre-published vs Self-configured

[Raguram1]

ServiceNow + Microsoft 365 Integration

Which Path to Choose? Pre-published vs Self-configured

The choice between Pre-published and Self-configured connection methods is one of the most important architectural decisions when integrating ServiceNow with Microsoft Teams and Microsoft 365. This guide provides a comprehensive comparison to help you make the right choice for your organisation.

At a Glance

Pre-published App ServiceNow-Managed A simple, out-of-the-box solution managed by ServiceNow. Ideal for organisations with a single instance and limited Azure expertise.

Self-configured App Customer-Managed A flexible, powerful solution managed entirely by you. Requires Azure expertise but offers complete control and scalability.

Pros & Cons

Pre-published App ✓ Pros Fast & simple setup Low effort deployment ServiceNow manages Azure app and permissions No Azure expertise required ✗ Cons Strict 1:1 mapping limitation Cannot connect Dev, QA, Prod simultaneously Major testing bottlenecks Not supported for GCC-H/DoD Azure Admin must access ServiceNow for consent

Self-configured App ✓ Pros Flexible 1:N mapping Full SDLC support (Dev, QA, Prod) Granular permission control Mandatory for regulated markets Supports strict role separation ✗ Cons High effort to set up Requires Azure portal expertise Customer maintains Azure application More complex initial configuration

Detailed Comparison

Feature / Aspect	Pre-published App (ServiceNow-Managed)	Self-configured App (Customer-Managed)
Instance Mapping	Strict 1:1 (one ServiceNow instance per Azure tenant)	Flexible 1:N or N:1 (multiple instances per tenant)
Security Control	Fixed permissions set by ServiceNow; changes may require re-consent	Full customer control with granular API permissions
Connectivity	Uses ServiceNow collaboration proxy	Direct connection to Microsoft Azure
Best For	Simple setups with low Azure expertise; single environment testing	Complex environments needing full SDLC and security compliance
Regulated Markets	✗ Not supported (e.g., GCC-H, DoD)	✓ Mandatory for regulated environments
Administrative Control	ServiceNow manages the Azure application	Customer creates and maintains in their tenant
Role Separation	Azure Admin must access ServiceNow to grant consent	Azure Admin works entirely in Azure portal; credentials handed to ServiceNow team

Which Path Should You Choose?

To help determine the most suitable path for your organisation, consider the following scenarios:

🚀 Choose Pre-published if: You have only one ServiceNow instance and one Microsoft tenant You want fast, low-maintenance deployment You're doing initial testing before committing to architecture Your team has limited Azure expertise You have multiple Azure tenants available and can leverage them for different environments (Prod on primary tenant, Dev/QA on secondary)

🛡️ Choose Self-configured if: You need Dev, QA, and Prod connected to same tenant You operate in regulated sectors (GCC-H/DoD) Your security team requires least-privileged access You need granular control over API permissions Your organisation enforces strict role separation where Azure Admins should not have access to ServiceNow—even for one-time setup activities

Critical Customer Learnings

1. The SDLC and Testing Bottleneck

One of the most significant real-world challenges with the pre-published approach is the limitation on testing and iteration.

• Testing Constraint: Because the proxy table only holds unique Azure tenant IDs, you cannot have your Production, Staging, and QA instances connected to your corporate Microsoft tenant simultaneously.
• Operational Risk: To test a fix or upgrade in a lower environment, you would have to uninstall your Production connection first, leading to unacceptable downtime.
• The Solution: The self-configured approach allows a realistic SDLC. You can create a distinct Azure app for each ServiceNow instance within the same tenant.

💡 Multi-Tenant Strategy for Enterprise Customers

Enterprise organisations with multiple Azure tenants/domains within their Entra ID environment can leverage a multi-tenant strategy with Pre-published:

• Production instance → Connect to your primary/main Azure tenant
• Dev/QA/Staging instances → Connect to secondary Azure tenant(s)

This approach allows customers to maintain the simplicity of Pre-published while still supporting a full SDLC across environments. Note: This option is available to organisations that have multiple Azure tenants/domains configured in their environment.

2. Security Posture and Granular API Control

Security teams often require precise oversight of what data an integration can access.

• Fixed Permissions: The pre-published app uses bundled permissions maintained by ServiceNow. Adding new features may require an Azure Global Admin to re-consent to the entire app.
• Regulated Markets: If your organisation operates in GCC-H or DoD, the self-configured approach is mandatory. Microsoft policies in these sectors often prohibit proxy-based communication.
• Customization: Self-configuration allows your security team to grant least-privileged access required for your specific use cases.

3. Addressing the Persona and Workflow Mismatch

The administrative effort for these integrations often falls across two different teams: ServiceNow Admins and Azure (Entra ID) Admins.

• Workflow Friction: In the pre-published model, the Azure Admin must often log into the ServiceNow instance to consent to the app—a platform they typically don't use, creating security concerns.
• Azure-Native Workflow: The self-configured approach aligns better with standard IT operations. The Azure Admin can perform all tasks within the Microsoft Azure portal, simply providing credentials to the ServiceNow team.

4. Role Separation Requirements

For organisations with strict governance policies, the choice of connection method can significantly impact operational workflows.

• The Challenge: Some organisations enforce policies where Azure Admins must never access external platforms—even for one-time setup activities. The pre-published approach requires the Azure Admin to log into ServiceNow to grant consent, which violates this separation of duties.
• The Solution: With self-configured, the Azure Admin works entirely within the Azure portal—creating the app registration, configuring permissions, and generating credentials. These credentials are then securely handed off to the ServiceNow team to complete the integration. Neither team needs access to the other's platform.

Think of it this way: The pre-published app is like a pre-configured appliance—it works instantly out of the box with minimal effort but cannot be modified or used in complex ways. The self-configured approach is more like custom-built infrastructure—it requires a skilled team to design and assemble it, but it provides the power and flexibility to handle a massive enterprise with diverse security and testing needs.

Related Resources

• ServiceNow Documentation: Pre-published App Configuration
• ServiceNow Documentation: Self-configured App Configuration
• Best Practices: ServiceNow for Microsoft Teams (FAQs)

Have questions? Leave a comment below or check out the full FAQ article for more details.