Integration Pages in XTM One
This page complements Integrations in XTM One.
That guide explains when integrations matter. This page explains what the integration screens show and how to use them.
What you see in the sidebar
In the left navigation, this area appears as Integrations.
The list page title is also Integrations.
Integrations list page
The list page is designed to answer a practical question fast: which external connections are usable right now.
Users come here to:
- search integrations by name or provider when you know the system you need but not the exact connection label
- filter by visibility to distinguish private, shared, and company-managed integrations
- filter by tags to narrow the list to one workflow, team, or operational domain
- filter by category when several categories exist, for example to focus only on messaging, document, or developer integrations
- compare connection state across integrations before deciding where the real problem is
- open one integration and understand whether it is ready, partially configured, or waiting for authorization
- create a new integration when you have permission and need agents to work with a new external system
The header contains:
- page title
Integrations - explanation that credentials are encrypted in the database
New Integration
The filter row can include:
- search field
- visibility filter
- tag filter
- category filter
- total count
Integration cards
Each integration card is status-heavy by design.
It shows:
- provider logo
- integration name
- provider name
- connection status badge
- company-managed or shared state
- credential readiness indicators
- tags or scope count
This matters because the list page is already a health dashboard:
- a connected integration is usually ready for agent use
- a configured but not authorized integration still needs work
- a re-authorization state often means permissions changed rather than that the integration disappeared
The status badge is especially important because it can represent more than simple connected or disconnected states. For example:
- connected
- configured
- disconnected
- re-authorize
That means the list page already gives you a useful troubleshooting signal before you open the detail page.
Empty states on the list page
If no integrations exist yet, the page encourages the user to create a first integration for services such as Gmail, Outlook, GitHub, or Slack.
If integrations exist but the filters remove them all, the page shows No integrations matching your filters.
Integration detail header
When you open an integration, the header shows:
- back button to
Integrations - integration name
- provider label
- status badge
- company-managed, shared, and read-only states when relevant
The header actions can include:
- setup guide
Test ConnectionAuthorizeorRe-authorize- delete
In practice:
setup guideexplains provider-specific prerequisitesTest Connectionvalidates the live connectionAuthorizeandRe-authorizeresolve OAuth state- delete removes the connection for every dependent usage
Authorize appears only when it makes sense for the integration type and ownership context.
Tabs on the detail page
The detail page contains:
OverviewConfigurationActivity
Overview tab
The Overview tab combines status, usage, and related entities.
Its KPI row shows:
- number of agents using the integration
- number of available tools, including read and write split
- tool call count
- last activity
The main connection card shows:
- authentication method
- credential readiness
- authorized scopes
- missing scopes when re-authorization is needed
- warning copy when permissions changed
- authorize or re-authorize action when relevant
- timestamps
This is the main screen to read when the user wants to know not only whether the integration works, but why it does or does not work.
The rest of the overview shows:
- an
Agents Usingcard - a
Knowledge Bases Usingcard when this integration powers sync sources
Configuration tab
The Configuration tab is a richer screen than most other resource types.
It can include:
- main configuration card
- available tools card
- event triggers card
- webhooks card
The main configuration card can expose:
- name
- description
- tags
- authentication mode
- OAuth client fields
- API key or bot token fields
- extra provider-specific configuration
- company-managed and sharing settings
The important idea is that this tab mixes three different concerns:
- identity of the integration
- authentication and provider setup
- visibility and reuse inside the workspace
The description field matters more than many people expect, because the UI explicitly explains that it is passed to agents as tool context.
Available tools card
The Available Tools card shows the actions the integration makes available to agents.
It groups tools into:
Read ToolsWrite Tools
That distinction matters because it helps you understand risk and expected behavior:
- read tools retrieve or inspect information
- write tools can change something in the connected system
When the integration is connected, you can hover a tool and test it with real credentials. That makes this screen the main place to validate capability before binding the integration to an agent.
Event triggers card
If the provider supports events, the Event Triggers card explains:
- event label
- delivery mechanism such as webhook, polling, or hybrid
- what the event means in business language
This is useful when the user is trying to understand whether an agent can react automatically to external changes.
Webhooks card
The Webhooks card changes depending on the provider.
It can show:
- a managed notification path
- a webhook URL to copy
- instructions about automatic delivery to agents
- a managed GitHub webhook section
This is where the integration page becomes especially concrete, because you can see how external events enter XTM One and, in some cases, configure that path directly.
In the GitHub case, you can create and remove repository webhooks directly from the UI if you have permission. This makes the page a working screen, not only a configuration display.
Activity tab
The Activity tab is the place to check:
- when the integration changed
- whether connections were tested recently
- whether an operational issue started after a configuration edit
Read-only and managed nuances
Integrations can have slightly more nuanced edit behavior than other resources.
For example:
- company-managed integrations can be read-only for non-admins
- some suite-level registrations can behave more like centrally managed records than like personal editable connections
The page remains useful because status, tools, and related usage stay visible even when editing is restricted.
Good customer habits on these pages
- Read the status badge before editing anything.
- Use
Test Connectionbefore assuming the agent is broken. - Use the
Available Toolscard to understand what the integration really provides. - Check scopes and re-authorization warnings when OAuth behavior changes.
- Look at
Agents Usingbefore editing a shared integration.