Support Boundaries Shared Responsibility Model

Topic

This article describes NinjaOne's scope of support responsibility for our various integrations, including limitations and what to expect if an issue falls outside our scope.

Environment

• NinjaOne Integrations
• ServiceNow
• FreshService
• Zendesk
• ConnectWise Manage
• Autotask

Description

When you connect NinjaOne to a third-party platform through our integration applications, your work syncs across two separate products, two separate codebases, and two separate support organizations. This interaction provides purpose-built tools for each job, but it also means that if an issue occurs, you must determine where the problem originated before you can fix it.

Index

Select a category to learn more:

• Core Principle
• Responsibility Matrix
  • Documentation Responsibility
• How NinjaOne Helps You
• Limitations of NinjaOne Support
  • Third-Party Platform Configuration
  • Custom Workflows, Automations, and Business Rules
  • Third-Party Platform API Behavior and Rate Limits
  • Non-OOTB Configurations, Field Mappings, and Environment Customizations
  • Third-Party Platform Licensing and Access Permissions
  • Third-Party Platform Outages and Performance
• Support Coordination and Handoffs
• How to Identify Where a Problem Lives
• Status Pages for Supported Integrations
• When to Engage NinjaOne Support vs. Third-Party Support
• Additional Resources

Core Principle

Think of a NinjaOne integration as a bridge between two platforms. NinjaOne owns and is responsible for our side of the bridge, the construction, the maintenance, and the traffic we send across it. The third-party platforms own their side of the bridge. You, as the partner, decide what data crosses the bridge and how to configure the traffic on each end.

When something breaks, it is important to determine on which side of the bridge the problem has occurred, because we only have the tools, access, and context to fix the problems that occur on our side.

Our Commitment

Our goal is never to leave you without a path forward. Even when a problem lives outside our scope, our job is to help you understand where it lives and how to get it resolved. When you engage NinjaOne support on an integration issue, we will:

• Perform a genuine investigation on our side before redirecting you elsewhere.
• Clearly explain why an issue is outside our scope.
• Help you formulate the correct question and summary to take to the third-party vendor, so your handoff is productive.
• Support you if you find yourself caught between two vendors. We will help identify the correct escalation path and make sure we cover all steps.
• Own any integration bugs we discover and communicate resolution timelines.
• Ensure this article remains accurate and up to date as our integrations evolve.

Providing Feedback on This Article

If you encounter a scenario that we have not addressed in this article, or if you feel a boundary is unclear or inaccurate, we encourage you to inform us through your NinjaOne support representative. This article is a living resource and improves with real-world input.

Responsibility Matrix

The following table defines ownership across the key layers of each NinjaOne-built integration.

Documentation Responsibility

NinjaOne will provide documentation in our Dojo to help you configure an integration connected through NinjaOne. Some of these integrations involve workflows that require you to perform actions on the third-party platform; in these situations, NinjaOne will also provide documentation to help you perform those steps.

NinjaOne will not provide documentation for third-party platforms if it does not directly affect the integration in NinjaOne, but we may provide external links to certain resources where applicable. You must refer to the third-party proprietary documentation for help using their product.

How NinjaOne Helps You

When you open a support case related to an integration, NinjaOne will take the following actions depending on the issue:

• Verify the integration connector is functioning as intended. We can confirm that our side of the integration is live, that the connector is passing data, and that the integration version you're running is current and supported.
• Validate your configuration against the out-of-the-box (OOTB) setup. Using our documentation as the baseline, we'll walk through the standard configuration steps with you to confirm the NinjaOne-side configuration matches our recommended OOTB setup. If necessary, we will update our documentation to provide clarity or troubleshooting steps.
• Reproduce issues in a controlled environment. If a behavior appears to be a bug within NinjaOne's integration layer, we will attempt to reproduce it using OOTB settings and escalate to our Engineering Team if confirmed. Note that this will take time; lab environments don't always reflect real-world configurations, diagnostic data from the original report may be incomplete, and engineering availability varies. We will keep you updated on statuses and timelines throughout the process.
• Identify and document integration bugs. If we identify a defect on our side of the integration, we own it; we will log it, communicate timelines for expected fixes, and provide workarounds where possible until the issue is completely resolved.
• Help with authentication and connectivity setup. We'll guide you through generating API credentials, configuring the connection in NinjaOne, and testing basic connectivity.
• Provide integration-specific documentation and setup guides. Our Dojo contains step-by-step setup instructions for each supported integration, including field mapping guidance for OOTB configurations.

Limitations of NinjaOne Support

The following sections describe areas that are outside of what NinjaOne Support can diagnose, modify, or resolve. In each case, the constraint is access; we cannot view the tools, data, or systems required to investigate because a third party owns them.

Third-Party Platform Configuration

We cannot access your account information inside a vendor platform, so we cannot view those configured workflows, permissions, field configurations, or custom rules. When behavior appears correct in NinjaOne but is not working as expected on the third-party platform, that is a signal to engage the third-party Support Team.

Custom Workflows, Automations, and Business Rules

Many partners extend their ITSM or PSA platforms with custom automations, triggers, business rules, or scripting. These are entirely outside NinjaOne's visibility and control. When a custom workflow interacts unexpectedly with data NinjaOne sends, debugging that workflow requires access to the third-party platform, which only you or that platform's support team has.

Third-Party Platform API Behavior and Rate Limits

Each third-party platform enforces its own API policies, including rate limits, authentication requirements, payload constraints, and deprecation schedules. When a platform changes its API behavior, or when your account hits a rate limit enforced by the third-party vendor, NinjaOne cannot override those constraints. We will adapt our integration when platforms make breaking API changes, but we cannot control the timeline or the behavior itself.

Non-OOTB Configurations, Field Mappings, and Environment Customizations

NinjaOne ships integrations with a set of default field mappings and settings designed to work out of the box. We support and document these OOTB configurations, and we validate expected behavior across our partner base. When you customize mappings, add field transforms, or route data in ways that deviate from the documented defaults, those customizations become your responsibility to maintain and troubleshoot.

This customization extends beyond obvious changes like field mappings. Modifications to access control lists (ACLs), role-based permissions, API user scopes, or platform-level security policies in the third-party environment can silently prevent OOTB integration behaviors from functioning, even when everything on NinjaOne's side is correct. These changes are often invisible to us, and may be only visible to the administrator or team who created them.

This boundary exists because our validation occurs only in OOTB environments. When default settings work across thousands of partner deployments, an issue isolated to one environment points to that environment, not the integration. Modifications to ACLs, permissions, or platform security policies can silently break expected behavior even if you believe your setup is unchanged. Diagnosing those changes belongs with your platform administrator or the third-party support team.

Third-Party Platform Licensing and Access Permissions

If your integration stops working because of a revoked API credential, deactivated user account, insufficient subscription access, or a permissions change made in the third-party platform, these are account-level changes that are part of your management or the third-party vendor's support.

Third-Party Platform Outages and Performance

If you are experiencing an outage or degraded performance on the third-party platform, NinjaOne cannot remediate the situation. We recommend bookmarking the status pages of your integrated platforms provided in the section of this article titled Status Pages for Supported Integrations, so you can quickly rule this out when troubleshooting.

Support Coordination and Handoffs

NinjaOne Support operates within, and our support access is strictly limited to, the NinjaOne environment. The following table describes what we can or cannot do on your behalf when you experience issues outside the NinjaOne environment.

How to Identify Where a Problem Lives

Prior to opening a support case, either with NinjaOne or a vendor, perform the following steps to identify ownership so that you can contact the correct team quickly.

1. Check the platform status: Visit the status page for your integrated platform. If there's an active incident, the status page should record it.
2. Check the integration version on the third-party platform: NinjaOne typically installs an integration as a client app within the third-party platform. Navigate to the app or connector settings in that platform to confirm settings and verify that you are running the current version. Outdated integrations can cause unexpected behavior, and this is one of the first things our Support Team will want to verify.
3. Test the issue with OOTB settings: If you have customizations in place (custom field mappings, modified workflows, or similar), temporarily deactivate them and test using default settings. If the issue goes away, the customization is the likely cause.
4. Check NinjaOne's integration activity logs: NinjaOne provides activity and error logs for each integration. If logs show successful outbound payloads from NinjaOne, the issue is likely on the receiving end. This information will form the basis of your Diagnostic Summary if you need to escalate to a third party.
5. Check the third-party platform's audit or activity logs: Most platforms maintain an API activity or audit log. If NinjaOne shows we are successfully sending data, but the third-party platform shows no record of receiving it, or shows errors on receipt, that's a strong signal about where to focus.

Status Pages for Supported Integrations

Use the following table as a guide to access the status pages for various vendors.

When to Engage NinjaOne Support vs. Third-Party Support

Use the following table as a guide to determine when to reach out to NinjaOne Support or a third party.

Additional Resources

Refer to Integrations and Third-Party Apps: Resource Catalog to learn more about our integrations.