| ★ New to Microsoft Teams Integration? Pre-published vs Self-configured: Which path is right for you? Compare features, limitations, and security considerations to make the right architectural decision. |
On this page
|
Getting Started Pre-published vs Self-configured
Installation & Configuration |
Clone & Migration Customization & Features
Troubleshooting |
FAQs
- If my requirement is only Virtual Agent chatbot integration with Microsoft Teams what is the plugin that we are supposed to install?
- If the need is to have only chatbot (Virtual agent) in Microsoft Teams, kindly install only Glide Virtual agent and Conversational Integration with Microsoft Teams plugins to integrate Virtual Agent in Microsoft Teams. See documentation here
- When do I need ServiceNow for Microsoft Teams group of apps?
- See this article to understand various features offered in this app.
- What are tenancy's and how to understand the application tenancy's?
- Learn about it here. Understand that only creation of application is linked to the tenancy in ServiceNow for Microsoft Teams integration context.
- What does Pre-published and Self-configured apps mean? (previously labeled as Multi-tenant and Single-tenant apps)
- Pre-published apps: This Azure Enterprise application is maintained by ServiceNow. This Application uses Proxy to enable communication between Microsoft Azure tenant and ServiceNow instance, the mapping has a limitation that it can hold only unique Azure tenant ID in the table. Hence the limitation of 1 ServiceNow instance to 1 Microsoft Azure Tenant (1:1 mapping).
- Self-configured app: This Azure application (App registrations) should be created/maintained by Customer within their Microsoft Azure Tenants (1:N mapping). There are no limitations in this configuration. Use cases include:
- When customer has multiple ServiceNow instances (Staging, QA, Prod) and has only one Microsoft Azure tenant to work with. In this case customer can create one Azure application per instance from https://portal.azure.com. The configuration steps are listed in ServiceNow documentation.
- When customer has a requirement to use one ServiceNow instance and connect multiple Azure tenants (with guest configurations).
- ServiceNow for Microsoft teams and Virtual Agent custom bot installation, there are two manifests which one should I upload?
- When you create a custom bot as per steps here, you will also be recommended to upload manifest. We suggest, when customer is using ServiceNow for Microsoft Teams manifest generation UI page, the manifest that is generated here will take care of VA as well. Observe the step mentioned here for "Configure virtual agent", since we are choosing the newly integration custom bot already, the manifest will have the information. Just uploading one manifest will do the job.
- How can I decide which path I should choose? Pre-published or Self-configured path?
- It is recommended to understand both the configurations and choose based on the Azure tenant and ServiceNow instance infra setup. If there is only one tenant and multiple ServiceNow instances where the use case is to move instance configuration in stages like dev, qa and prod, it is advisable to use the Self-configured approach. You can choose Pre-published as well, but as per limitation it can have only one active connection with an instance and Azure tenant. If one wants to connect the second instance they will have to first uninstall the existing connection and then connect the new one. See the detailed comparison section below for a comprehensive breakdown.
- How to change our existing setup from Pre-published to Self-configured setup?
- If an instance was previously configured with pre-published and now want to be configured with self-configured, follow below steps.
- Go to ServiceNow for Microsoft Teams -> Install Azure Apps and click on Uninstall button. Verify the tenant configured in module ServiceNow for Microsoft Teams -> Tenant Connections to make sure the uninstall was successful.
- Now follow the documentation of integrating self-configured app, you should be able to change your setup from Pre-published configuration to Self-configured configuration.
- Do we need two different Azure apps for Virtual Agent self-configured bot and ServiceNow for Microsoft Teams authenticate users App?
- Short answer: Yes
- Long answer: This usually happens when both Virtual Agent (bot) and authenticate App (tab SSO) are using self-configured path. There will be two apps: for Virtual Agent bot, which will be created from developer portal, and for authenticate users, which you will create from Azure portal. The configuration for these two apps is separate and ServiceNow side configuration is also separate.
app creation difference
- What are the tables should I preserve for clone?
Table label Table name Azure App sn_now_azure_appMicrosoft Azure Credentials sn_now_azure_credentialsInstalled App sn_now_azure_installed_appInstalled Tenant sn_now_azure_installed_tenantAzure User Token sn_now_azure_tokenAzure User Mapping sn_now_azure_userTeams Guest User Chat Configuration sn_now_azure_tenant_mapping - Can both Pre-published and Self-configured exists in one ServiceNow instance?
- This is not a supported configuration.
- Why should I modify OOB generated oidc_provider_configuration User field value for TAB SSO feature?
- Not always the environment is configured to use sys_user.email (field) as primary user email field. Most of the times it is configured in User ID field which is used for login as well. So it is necessary to review oidc_provider_configuration record and update based on requirement.
- 1. User Claim - this parameter is picked from the token.
2. User Field - this is picked from sys_user table. The value of this column and upn mentioned in User Claim field should be matching.
- My requirement is to only have EmployeeCenter tab within the BOT, can I remove the CHAT tab in that case?
- Yes it is possible, see KB here.
- I want to re-order the TABS with the ServiceNow for Teams App, is this possible?
- Yes it is possible, see KB here.
- I want to configure and allow Guest users in Start Microsoft Teams chat feature, how can I achieve this?
- We have a new feature introduced in November 2022 called Guest user access for Start chat and Import chat messages features. Please see documentation here.
- Does Manifest generation support localisation?
- Yes, when the OOB manifest record is used to generate the manifest, we are shipping the equivalent translated strings for all the ServiceNow supported languages. The downloaded ZIP should contain all the translations as well.
- However, the moment users click on "new" from the manifest list view, the translations should be taken care by the user for all supported languages, string needs to be saved per language.
- Can we customise VA Actionable notifications that are triggered via BR shipped in Microsoft Integrations - Core?
- Unfortunately no, this specific BR triggered VA Actionable notification is not allowed to be customised.
- Cross-Origin error when trying to load the portal tab in Microsoft Teams
- If the portal used is a custom portal then customer has to create respective sys_response_header, if the sys_response_header record exists, please verify the table records and its order. Sometimes if there is a GLOBAL application scoped sys_response_header.
Choosing Between Pre-published and Self-configured Connection Methods
The choice between the pre-published and self-configured connection methods depends on an organisation's architectural complexity, security requirements, and long-term scaling needs. The following table provides a neutral summary of the capabilities and constraints for both approaches.
Comparison of ServiceNow and Microsoft 365 Connection Methods
| Feature / Aspect | Pre-published App (ServiceNow-Managed) |
Self-configured App (Customer-Managed) |
| Mapping Capability | Strictly 1:1 (one ServiceNow instance to one Azure tenant). | Flexible 1:N or N:1 (many instances to one tenant or vice versa). |
| Primary Advantage | Speed and Simplicity: Faster setup with lower Microsoft Azure expertise required. | Control and Scalability: Supports complex multi-instance environments and granular security. |
| Connectivity Path | Uses a ServiceNow collaboration proxy for communication. | Establishes a direct connection to Microsoft Azure, bypassing the proxy. |
| Administrative Control | ServiceNow manages the Azure application and updates. | The customer creates and maintains the application within their own tenant. |
| Regulatory Fit | Often unsuitable for GCC-H or DoD due to proxy-based restrictions. | Mandatory for regulated markets like GCC-H and DoD to ensure policy compliance. |
| Permission Management | Uses bundled/predefined permissions; changes may require re-consent. | Offers granular control over API permissions to align with strict security postures. |
Navigating the Choice Between Approaches
To help determine the most suitable path for an organisation, consider the following environmental factors:
- For Speed and Limited Scope: If an organisation has only one ServiceNow instance and one Microsoft tenant and prioritises a fast, low-maintenance deployment, the pre-published app is an efficient choice. This path is also useful for initial testing in a single lower environment before committing to a permanent architecture.
- For Robust SDLC and Testing: Organisations that need to continuously iterate on features like request-based chat will find the self-configured approach beneficial. It allows for a realistic Software Development Life Cycle (SDLC) by linking Dev, QA, and Production instances to the same Microsoft tenant, enabling defect testing and upgrade validation without touching the live environment.
- For High-Security or Regulated Environments: If an organisation operates in regulated sectors (GCC-H/DoD) or has a security team that requires least-privileged access via specific API scopes, the self-configured approach is the necessary architecture.
- Customised Security Postures: If a security team requires "least-privileged access" and needs to review or modify every individual API permission granted to the integration, the self-configured approach provides the necessary transparency and control.
The pre-published app is similar to 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 a 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.
Critical Customer Learnings & Considerations
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 Software Development Life Cycle (SDLC). You can create a distinct Azure app for each ServiceNow instance within the same tenant, allowing you to validate changes in a sandbox before rolling them out to production with zero risk to the live 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 a bundled set of permissions maintained by ServiceNow. Adding new features may require an Azure Global Admin to re-consent to the entire app, which can be a slow and complex process in large organisations.
- Regulated Markets (GCC-H/DoD): If your organisation operates in a regulated environment like GCC-H or DoD, the self-configured approach is mandatory. This is because Microsoft policies in these sectors often prohibit the proxy-based communication used by the pre-published app.
- Customization: Self-configuration allows your security team to grant the least-privileged access required for your specific use cases, ensuring compliance with internal security standards.
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. This is frequently a platform they do not use, creating a "persona mismatch" and potential security concerns regarding account access.
- Azure-Native Workflow: The self-configured approach aligns better with standard IT operations. The Azure Admin can perform all high-privilege tasks—such as creating app registrations and assigning scopes—entirely within the Microsoft Azure portal, simply providing the final credentials to the ServiceNow team for the connection.
Most Common Errors with resolution
Error: "Error while authorising user" error when trying to access "Employee Center" tab (Your hub/Teams tab)
Solution: Make sure the associated oidc_provider_configuration User claim and User field point to the right values. OOB we ship User field as "Email" — this could be different for different customers.
Error: Shows resourceDisabled when trying to open the "Employee center" tab
Solution: Please review the documentation step where it is mentioned Navigate to Manage > Expose an API and set application URI. Make sure api://<instance-url-without-http>/<client-id> is set properly. Review steps 15-23 once again to ensure correct values are set.
Error: Chatbot is not responding after configuring ServiceNow for Teams
Cause: One of the common issues can be because of the steps to block and unblock the 'Now Virtual Agent' from app permissions mentioned here.
Solution:
- First: Make sure the order of installation of Virtual Agent, uploading of ServiceNow for Teams manifest and blocking of 'Now Virtual Agent' app (available in store) is followed as mentioned in the documentation.
- Second: Make sure IP access is not blocking Microsoft Teams related IP addresses. See KB1122698.
- Third: If you have org-specific permission policy to allow specific apps only in "Third party apps" and "Custom apps", make sure you have the "Now Virtual Agent" in the allow list of "Third party apps" and at the same time it is blocked.
Error: TAB does not load the right portal. [I want to configure a custom portal, but TAB redirects to eesp or esc portal after uploading manifest or editing manifest.json "websiteUrl" value]
Solution:
- Firstly, the
websiteUrlJSON property does not represent the URL that will load inside of the tab. - Refer to the documentation explaining what steps need to be done to render the custom portal onto the Microsoft Teams TAB.
