# Connect to Your Existing Systems

Connectors let you pull feedback into BoundaryAI directly from the tools your team already uses — support desks, project trackers, and developer platforms — and analyse it alongside surveys, uploads, and scraped reviews. Once connected, a platform keeps feeding new tickets and conversations into your Feedback Groups automatically, with no exports, no copy-pasting, and no scheduled scripts.

This page covers how connectors work end-to-end: what platforms are supported, how to connect one, how to configure what you import, and how the imported data behaves once it lands in BoundaryAI.

For the container that holds connector data, see Feedback Groups. For other ingestion paths, see Uploading\
Data, Web scraping, and Creating a Survey.

***

### When to use a connector

Use a connector when:

* Your support team uses **Zendesk, Freshdesk, Intercom, Front, ServiceNow, HubSpot Service Hub**, or **Salesforce Service Cloud** and you want every customer ticket — past and ongoing — analysed for themes, sentiment, and flagged issues.
* Your product team tracks bugs and feature requests in **Jira, Linear, GitHub, GitLab, Asana, ClickUp, Trello, Shortcut, Wrike, or Teamwork**\
  and you want to mine those for recurring patterns.
* You want **always-on** ingestion: new tickets land in BoundaryAI within minutes of being created or updated in the source platform, without anyone exporting a CSV.

If your data is already exported as a spreadsheet, Uploading Data is faster. If you need responses from outside any platform you\
control (public reviews, social posts), see Web scraping.

***

### Supported platforms

BoundaryAI uses [Merge.dev](https://www.merge.dev/) to broker the connection, which means a single OAuth flow gives you access to a unified set of "ticket" objects regardless of vendor. Three categories are supported today:

#### Customer support & service

Zendesk, Freshdesk, Intercom, Help Scout, Front, ServiceNow, Salesforce Service Cloud, HubSpot Service Hub, Kustomer.

#### Project management

Jira, Asana, Linear, ClickUp, Trello, Shortcut, Wrike, Teamwork.

#### Developer tools

GitHub, GitLab.

Each platform exposes a slightly different feature set on the source side — for example, *priority* and *due date* exist in Jira but not in Trello, *ticket type* in Zendesk but not in Linear. BoundaryAI knows what each platform supports and only shows configuration options that are actually applicable, so you never see a filter that does nothing.

> **Don't see your tool?** The full Merge catalogue covers 39+ platforms; the list above is what's available out-of-the-box. If you need one\
> that isn't listed, contact us via the upgrade prompt in-app.

***

### Plan availability

Connectors are available on the **Standard** plan and above. Starter-plan users see the catalogue but the *Connect* action is replaced with an\
upgrade prompt. Within an entitled plan, every supported platform is available — there are no per-platform paywalls.

***

### Connecting a platform

The flow takes about a minute and runs entirely inside BoundaryAI; there is nothing to install on the source platform.

#### Where to start

There are two entry points:

* **Integrations Hub** (`/integrations`, *Native Connectors* section) — for setting up new connections without choosing a Feedback Group yet.
* **Inside a Feedback Group**, on the *Connectors* tab — when you already know which group the data should land in.

Both routes lead to the same authorisation flow.

#### The flow

1. **Pick a platform.** Click any tile in the platform grid.
2. **Authenticate.** A Merge Link modal opens; sign in with your platform credentials and authorise read access. The modal handles every vendor's specific OAuth steps (Zendesk subdomain, Freshdesk API key, Jira workspace, etc.).
3. **Confirm.** On success the platform appears in the *Connected* list with a green status badge. BoundaryAI receives a long-lived account token from Merge and never sees your platform credentials directly.

You can connect **one account per platform** per organisation. Reconnecting the same platform replaces the existing connection — useful if the\
original was set up by someone who has since left the team.

***

### Configuring an import

Connecting the account is step one. Step two — usually opened immediately afterwards — is telling BoundaryAI what to bring in.

#### Pick a destination Feedback Group

Choose which Feedback Group the imported tickets should land in. Most teams create a dedicated group per source ("Customer Support — Zendesk", "Engineering Bugs — Jira"); some prefer a single group that mixes channels. Either works.

#### Choose a time range

| Option                            | Imports tickets created in…                |
| --------------------------------- | ------------------------------------------ |
| Last 7 / 30 / 90 / 180 / 365 days | …the chosen window.                        |
| All time                          | …the entire history of the source account. |
| Custom range                      | …a specific start-and-end window.          |

BoundaryAI shows an estimated ticket count for the chosen range so you can size the import before pressing Start.

#### Apply filters

Filters narrow what gets imported. Available filters depend on the source platform:

* **Status** — open, closed, in progress, on hold (or *all*).
* **Priority** — urgent, high, normal, low (or *all*).
* **Ticket type** — bug, feature, question, task, incident, etc.
* **Assignee** — assigned, unassigned, or *all*.
* **Due date** — overdue, due today, due this week, no due date, or *all*.
* **Collections** — multi-select picker for the platform's native containers (Jira *Projects*, Trello *Boards*, Zendesk *Groups*, Freshdesk\
  \&#xNAN;*Groups*, GitHub *Repositories*, etc.).

Filters apply to both the initial bulk import and to every continuous-import sync after it, so a "support tickets, closed, last 30 days" connector will keep importing freshly-closed support tickets in subsequent cycles, not random new ones.

#### Pick the fields to import

The field selector lets you choose exactly which Merge **common-model fields** (status, priority, assignees, tags, etc.) and which **platform-specific remote fields** to pull. Common-model fields land as structured metadata, available for segmentation in the analysis view; remote fields are useful when your team relies on custom Zendesk tags, Jira fields, or similar that aren't in the common model.

If you don't want to think about this, leave the defaults — they cover the fields almost everyone uses.

#### Toggle continuous import

A single checkbox controls whether the connection is **one-shot or always-on**:

* **One-shot** — imports the matching tickets once, then stops. New tickets created later in the source platform will not appear unless you\
  re-import manually.
* **Continuous** — imports the initial batch *and* keeps pulling new and updated tickets on a recurring 30-minute cadence.

Most teams choose continuous; one-shot is useful for historical migrations.

***

### The initial import

When you press **Start import**, BoundaryAI:

1. Creates an *import job* with a unique ID.
2. Kicks off a background task that paginates through the source platform via Merge.
3. Shows a progress toast in the corner of the screen — *"Fetching tickets…"* → *"Importing 240 / 410 to Customer Support — Zendesk"* → *"410*\
   \&#xNAN;*tickets imported. View analysis."*

You can navigate away and keep working; the toast follows you. When the job completes, the connector survey appears in its target Feedback Group with a *Connector* badge, and the *Open analysis* link becomes active.

Initial imports run with a per-import safety cap (5,000 tickets per cycle) to keep the system responsive — for very large historical migrations, the import is split across multiple cycles automatically.

***

### Continuous import

For connectors with continuous import enabled, BoundaryAI runs an incremental sync **every 30 minutes** in the background. Each sync:

1. Asks Merge for tickets created or updated since the last successful sync, with the configured filters applied.
2. De-duplicates against tickets already imported into BoundaryAI.
3. Runs the new tickets through the same theme/sentiment/flag pipeline as everything else.

The auto-import cadence is fixed at 30 minutes; on most plans, **manual** syncs are the right tool when you need fresher data than that.

#### Fetching new data on demand

From the connector's data-source card on the qualitative overview page (or from the surveys list), click **Fetch new data**. BoundaryAI:

1. Asks the source platform (via Merge) to refresh its cache from your Zendesk / Freshdesk / Jira / etc. *now* rather than waiting for its own\
   polling cycle.
2. Pulls any tickets the refresh surfaced.
3. Shows the result inline: *"Imported 3 new tickets"*, *"No new tickets to import"*, or an error message with detail.

The card displays the **exact "Last import" timestamp** and the **next auto-import ETA** so you always know how fresh the analysis is. The forced-refresh step is plan-gated on Merge's side; on dev / test accounts it is disabled and the sync falls back to whatever Merge has already pulled, which is still better than waiting 30 minutes.

#### Pausing, editing, and disconnecting

From the Integrations Hub or the connector's data-source card, you can:

* **Pause** continuous import — the connector stops syncing but retains its filters and field selection so you can re-enable later in one click.
* **Update filters** — change which tickets future syncs include without re-importing the past.
* **Disconnect** the linked account — stops all syncs, removes the link to Merge, and revokes the OAuth grant. Already-imported tickets stay in your Feedback Group; only the live link to the source platform is cut.

#### Failure handling

If a sync errors three times in a row (for example, your platform credentials expired), BoundaryAI surfaces the error on the data-source card with the exact message returned by Merge. After **five consecutive failures** the connector is auto-disabled to prevent error-loop noise; re-enabling it is one click once the upstream issue is fixed.

***

### What connector data looks like in a Feedback Group

Once imported, tickets appear as a single survey inside the destination Feedback Group, with a *Connector* badge so you can tell at a glance which sources are live.

Per-ticket mapping:

* The ticket **subject and body** become a Long Answer response — the field the AI analyses for themes and sentiment.
* **Comments** on the ticket are appended as additional context (where you opted to include them).
* **Status, priority, assignees, ticket type, tags, due date** become metadata fields, available for segmentation in the analysis view.
* Any **remote fields** you selected come through as additional metadata.

This means a connector survey participates fully in cross-source analytics inside its Feedback Group — Super-Themes will cluster connector tickets together with relevant survey responses or scraped reviews, and group-scoped reports include them automatically.

#### The data-source card

On the qualitative overview of a connector survey, a *Data Source* card surfaces:

* The connected platform (logo, name, status badge).
* **Last import** with full date and time-of-day precision.
* **Next auto-import** ETA, with a relative countdown ("in 12 m").
* The persisted filters as **read-only chips** (status: closed, priority: high, collections: 3 selected, etc.) so you can see exactly why some\
  tickets may be excluded.
* A **Fetch new data** button to trigger a manual sync.
* A direct link to the Integrations Hub for editing or disconnecting.

***

### The Integrations Hub

The Integrations Hub at `/integrations` is the central management surface for everything connector-related.

The *Native Connectors* section shows:

* A header with the count of connected accounts and a **Connect new** button.
* A **Connected accounts** list — one card per linked platform with status, connection date, and a disconnect button.
* The **available platforms grid** with a green checkmark on platforms you've already connected.
* A **Next steps** banner that links into Feedback Groups once you have at least one connection live.

Sibling sections of the same hub cover API Keys, Webhooks, and Web & Social scraping credits. They are intentionally separate from connectors because their auth model and use cases are different.

***

### Best practices

* **One Feedback Group per source per audience.** A single mixed group is fine for small operations; for larger ones, splitting *"Support —EU"*, *"Support — US"*, and *"Engineering bugs"* keeps Super-Themes meaningful.
* **Be specific with filters.** *"All tickets, all time"* is rarely what you want. Filter to closed support tickets if you care about resolved issues; filter to a single Jira project if you only analyse one team.
* **Pick remote fields you actually use.** The common-model fields cover most analyses; only add custom remote fields if your team uses them for routing, tagging, or escalation.
* **Use&#x20;*****Fetch new data*****&#x20;to validate the connection right after setup.** It surfaces auth issues immediately rather than 30 minutes later.
* **Don't worry about the 30-minute cadence.** BoundaryAI's fix for stale Merge caches and watermark races means tickets are not lost between syncs even if a sync returns empty — the next run will pick them up.
* **Re-authenticate proactively when seats change.** If the team member who originally connected the platform leaves, reconnect the integration so the long-lived token doesn't unexpectedly expire.
* **Disconnect, don't delete.** Disconnecting the connector keeps imported tickets and analyses available; deleting the survey loses them.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://boundaryai.gitbook.io/boundaryai-docs/basics/connect-to-your-existing-systems.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
