Connecting your existing stack to an IT automation platform should be fast, admin-led, and finished before the day is over. In Serval, most integrations go from zero to live in a guided OAuth flow that takes minutes. Once connected, pre-built workflows are available to install immediately. And every integration, whether it's a named connector or something you built yourself for an internal tool, operates under the same API scope ceiling that a Manager sets at connection time. That ceiling is a hard limit on what Serval can ever access for that integration. Flexibility and security aren't a trade-off here.

Why is integration setup hard with most ITSM automation tools?

Most ITSM automation platforms work well when your stack matches their pre-built integration list. When it doesn't, the path forward is usually either a professional services engagement, a custom connector built by your engineering team, or waiting for the vendor's roadmap to catch up.

The bigger problem is what happens even when your tool is on the list. Many platforms require you to configure API permissions manually, copy credentials between systems, understand the vendor's data model, and validate that the right scopes are in place before you can run a single workflow. That's not IT admin work. It's developer work. And it creates a situation where the people who most need automation, IT ops, help desk leads, and their managers, can't get started without pulling in engineering.

Serval is built to fix that. Connecting a new integration is something an IT admin can do on their own, usually in less time than it takes to write a ticket about the problem.

How quickly can you connect the tools your team already uses?

For integrations in Serval's library, setup follows a guided flow that handles authentication for you. The Okta integration is a good example. You can install it directly from the Okta Integration Network (OIN) catalog: log into your Okta admin console, find Serval in the app catalog, click Add Integration, copy the Client ID and Client Secret, and paste them into Serval. That's it. Serval's health check confirms the integration is working, and you're ready to build or install workflows.

Jira is even simpler. In Serval, go to Apps, find Jira, click Connect, and complete the OAuth flow. There's no manual configuration on the Jira side.

Slack uses the same OAuth pattern. You authorize the connection in Slack, return to Serval, and configure which channels the Help Desk Agent listens to. The whole setup happens inside Serval's UI without touching Slack's developer console.

The same guided model applies across the integration library: Google Workspace, GitHub, Workday, Rippling, Microsoft Graph (for Entra ID and Exchange), Jamf, Kandji, AWS, Jira, Confluence, and more. Each guide includes step-by-step instructions, the exact scopes to grant, and a health check that surfaces problems before you start building anything.

You don't need an engineer in the room. You need an admin with credentials.

What does your team get immediately after connecting an integration?

Connecting an integration in Serval doesn't just unlock API access. It surfaces a set of installable workflows: pre-built automations for that application that are ready to use without writing any code.

After connecting Okta, you get installable workflows for things like adding a user to an Okta group, removing a user from a group, creating a user with a temporary password, deactivating a user, suspending a user, assigning a user to an Okta application, and unlocking a locked account. After connecting Google Workspace, you get workflows for creating Google Workspace users, adding or removing users from Google Groups, creating Gmail delegates, managing calendar access, and creating user aliases.

Installing a workflow takes one click. The workflow lands in your team as a draft. You review the inputs, adjust approval requirements, configure who can trigger it, and publish. At that point, the Help Desk Agent can match incoming requests to that workflow and run it automatically.

This is what makes integration speed matter. The faster you connect a tool, the faster the workflows tied to that tool are available. And the more tools you connect, the wider the range of requests Serval can automate end-to-end without any IT team member touching the ticket.

Serval's Insights Agent also watches your help desk activity and surfaces suggestions for which installable workflows make sense given your ticket volume. You don't have to browse through a list and guess.

What if your tool isn't in the integration library?

The integration library covers 70+ applications across identity (Okta, JumpCloud, Google Workspace, Entra ID via Microsoft Graph), collaboration (Slack, Microsoft Teams, Notion, Confluence), developer tooling (GitHub, GitLab, Linear), device management (Jamf, Kandji, Mosyle), ITSM (Jira, ServiceNow, Freshservice, Zendesk), HR (Rippling, Workday, BambooHR, HiBob, Ashby, Justworks), cloud infrastructure (AWS), and security (CrowdStrike, Vanta, Rapid7).

When a tool isn't in the library, Custom App covers it. Custom App is a framework for connecting any third-party application that has an API. You give the app a name and domain, choose your authentication method (OAuth or API key), enter your credentials, and save. Serval creates a connection that works exactly like a named integration. Once connected, that application is available in the Automation Agent's workflow builder, and you can write workflows that call its API endpoints.

Custom App works for external SaaS tools your team uses that haven't made Serval's integration list yet. It also works for internal proprietary systems with an API, including tools your engineering team built in-house, internal HR or finance portals, or legacy systems that still have documented endpoints.

There's no difference in how the security model applies. API scoping, role-based permissions, and audit logging all work the same way for a Custom App connection as they do for a named integration.

What about internal proprietary tools that no integration library covers?

Custom App handles these too. If your organization built an internal ticketing system, an internal provisioning portal, or any other internal tool with an API, you can connect it to Serval the same way you'd connect any third-party SaaS.

The key constraint is that the tool needs an API. If it has one, you can configure a Custom App connection, scope what Serval can access, and write workflows against its endpoints in the Automation Agent's TypeScript-based workflow builder. IT admins at organizations with hybrid stacks, where some tools are commercial SaaS and others are internally built, can bring all of them into one automation layer.

One thing to note: credentials for Custom App connections are stored securely and never returned to the frontend after being saved. To update credentials, you re-obtain them from the source system and re-enter them. This isn't a workflow you need to do often, but it's useful to know going into setup.

How does the security model work at the integration level?

Every integration in Serval, whether named or custom, operates under an API scope ceiling that a Manager sets when the integration is configured.

The Manager role is specifically the team role that can configure integrations and manage team settings. Builders can create and edit workflows. Contributors can install installable workflows. Agents can run workflows and handle tickets. Only Managers can touch the integration configuration itself.

When a Manager connects an integration, they define what scopes that connection carries. For Okta, those might be `okta.users.manage`, `okta.groups.manage`, `okta.apps.manage`, and `okta.logs.read`. For Google Workspace, they choose from scopes covering user management, group management, Drive access, Calendar, Gmail delegation, and Sheets. For GitHub, they choose between an AI Engineer tier (code read/write, pull requests) and an Admin tier (that adds org member and team management).

Those scopes become the ceiling. Workflows built by anyone on the team, including Builders, can call any endpoint that falls within the configured scopes. They can't call anything outside them. No workflow can expand the scope of an integration. That decision belongs to the Manager, and it's made once at connection time.

This matters because it means the person responsible for security posture sets the ceiling, and then the people building automation can work freely within it. They don't need to check with security every time they add a new workflow step. The ceiling is already in place.

For Google Workspace specifically, the scope model is explicit: you can configure minimal scopes (user and group management only) or full scopes that include Drive, Sheets, Calendar, and Gmail delegation. The choice depends on what your workflows need, and the Manager can adjust scope if requirements change.

Why does this integration model make Serval flexible across heterogeneous stacks?

Most IT teams don't run a uniform stack. They have an identity provider (Okta, Entra ID, or JumpCloud), a ticketing system (Jira, ServiceNow, or Freshservice), a collaboration tool (Slack or Teams), a device management platform (Jamf or Kandji), an HRIS (Workday, Rippling, BambooHR, or HiBob), and a collection of other tools that accumulated over years of growth. Some of those tools are on every vendor's integration list. Some aren't.

Serval's approach is to make every connected tool available to the Automation Agent for workflow building. That's what enables automation across a heterogeneous stack. An onboarding workflow might touch Okta to create the user, GitHub to add them to the right team, Google Workspace to provision email and Drive access, Jira to create an onboarding tracker ticket, and Slack to send a welcome message. Each of those connections was set up independently, and each has its own scope ceiling. The Automation Agent coordinates across all of them inside a single workflow.

When a team connects a new integration, whether it's a named connector or a Custom App, the tools available to the Automation Agent expand immediately. Builders can write workflows that reference the new connection without waiting for anything to propagate or be reviewed by engineering. The connection is live, the scopes are set, and the Automation Agent can use it.

What's the practical path to getting started?

The fastest path is to connect the integrations your team relies on most, install the pre-built workflows relevant to those tools, and start with the automations that cover your highest-volume request types.

For an IT team handling a lot of access requests, that usually means starting with Okta or Entra ID (for provisioning and group management), Google Workspace or Microsoft 365 (for email and directory access), and Slack (for the Help Desk Agent to receive requests). Those three connections cover a large share of what employees request from IT, and each comes with installable workflows ready to use.

For teams where GitHub access management is a major part of the workload, connecting GitHub (Admin tier) and installing the team membership and repository access workflows handles a significant portion of those requests without custom workflow development.

For tools not in the library, the Custom App setup is the same admin-led process. The order of operations is: connect, scope, install or build.

Once Serval is connected to your stack and the Automation Agent can reach the relevant APIs, the path from "someone submitted a request in Slack" to "that request is automatically resolved without IT touching a ticket" is a workflow configuration, not an engineering project.

The integration setup is the foundation. Getting it right, choosing the right scopes, using the right authentication method, and understanding what each connected tool can do inside Serval's permission model, is what makes the automation layer reliable over time. The good news is that Serval's guided setup and Manager-scoped API ceiling handle most of that work for you at connection time, so your team isn't revisiting integration security decisions every time someone builds a new workflow.