Skip to main content
Pylon is a B2B customer support platform: it brings conversations from Slack, Microsoft Teams, email, chat and other channels into issues, and adds accounts, SLAs, surveys, a knowledge base and customer projects around them. This connector reads your Pylon workspace through its public API and brings your issues and every message on them, your accounts and contacts, users and teams, tasks, projects and milestones, survey responses, knowledge base articles, the configuration around them (tags, statuses, custom fields, ticket forms, macros) and the audit log.
The connector only reads data. It never creates, changes or deletes anything in Pylon.

Configuring Pylon as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Pylon option from the list of connectors. Click Next and you’ll be prompted to add your access.

1. Add account access

The connector signs in with a Pylon API token. Only Admins can create one: in Pylon, go to Settings > Integrations & dev > API tokens and click Create API Token. Give it a name and either pick a Role that can read the data you want to sync, or select a user or bot for it to act as (it then uses that user’s role). Leave the IP allowlist empty. Copy the token when it is shown, since Pylon shows it only once. See Pylon’s guide to API tokens.
Pylon deletes a token when the user who created it, or the user it acts as, is deactivated. Create the token from an account that will stay active, or with its own identity.
The following configurations are available:
  • API Token: The Pylon API token.
  • Region: Where your Pylon workspace is hosted, US or EU. Tokens that start with pylon_api_eu_ belong to the EU region, and tokens that start with pylon_api_ (without eu) belong to the US region.
  • Start Date: Earliest update date read by the incremental streams (issues, issue messages, tasks, projects, milestones and audit logs) on the first sync and on full syncs. The other streams are always read in full.
Once you’re done, click Next.

2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
Tip: The stream can be found more easily by typing its name.
Select the streams and click Next.

3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
  • Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
  • Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: you can choose between INCREMENTAL and FULL_TABLE.
    • Incremental: every time the extraction happens, we’ll get only the new data, which is good if, for example, you want to keep every record ever fetched.
    • Full table: every time the extraction happens, we’ll get the current state of the data, which is good if, for example, you don’t want to have deleted data in your catalog.
Once you are done configuring, click Next.

4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Optionally, you can define some additional settings:
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Once you are ready, click Next to finalize the setup.

5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your Catalog, you need at least one successful source run.
Pylon limits how many requests your workspace can make per minute, shared by every integration that uses your Pylon tokens. Issue messages are read with one request per issue, so the first sync of a workspace with many issues can take several hours. A recent Start Date makes it shorter.

Streams and Fields

Available streams

The table below lists every stream, its slug (the exact identifier to pass when creating the source via API) and a short description.
Nested information (custom fields, SLA details, authors, channels, answers and similar) comes as JSON text. The IDs most used in joins are also copied into their own columns: account_id, requester_id, assignee_id, team_id, owner_id, project_id and milestone_id.
Pylon does not report deleted records. In incremental tables (issues, tasks, projects, milestones), a record deleted in Pylon stays in your table; full-table streams drop it on the next sync.

Fields by stream

Support

Support issues (conversations and tickets) with their state, requester, assignee, team, tags, custom fields, SLA timings and CSAT. Synced incrementally by last update; an issue with new messages is read again too.Table: issues · Primary key: id · Sync: Incremental · Replication key: updated_at
Every message of each issue read in the sync: customer messages, replies and internal notes, oldest first. All messages of an issue are read again whenever the issue changes.Table: issue_messages · Primary key: issue_id, id · Sync: Incremental · Replication key: issue_updated_at
CSAT, NPS and custom surveys. Read in full on every sync.Table: surveys · Primary key: id · Sync: Full table
Responses to every survey, with their answers. Read in full on every sync, so responses later excluded from analytics are updated.Table: survey_responses · Primary key: id · Sync: Full table

Customers and team

Customer accounts (companies), with domains, owner, tags, channels and custom fields. Read in full on every sync.Table: accounts · Primary key: id · Sync: Full table
Contacts (people at your customer accounts). Read in full on every sync.Table: contacts · Primary key: id · Sync: Full table
Users (agents) of your Pylon workspace, deactivated ones included. Read in full on every sync.Table: users · Primary key: id · Sync: Full table
Teams, their members and how they assign issues. Read in full on every sync.Table: teams · Primary key: id · Sync: Full table
Roles users can have. Read in full on every sync.Table: user_roles · Primary key: id · Sync: Full table

Projects and tasks

Tasks of your projects and customer onboardings. Synced incrementally by last update.Table: tasks · Primary key: id · Sync: Incremental · Replication key: updated_at
Projects, with status and progress. Synced incrementally by last update.Table: projects · Primary key: id · Sync: Incremental · Replication key: updated_at
Project milestones (milestones of projects not launched yet are not returned by Pylon). Synced incrementally by last update.Table: milestones · Primary key: id · Sync: Incremental · Replication key: updated_at

Configuration and content

Tags for issues, accounts and articles. Read in full on every sync.Table: tags · Primary key: id · Sync: Full table
Issue statuses, built-in and custom. Read in full on every sync.Table: issue_statuses · Primary key: slug · Sync: Full table
Task statuses, built-in and custom. Read in full on every sync.Table: task_statuses · Primary key: slug · Sync: Full table
Custom field definitions of accounts, issues, contacts, tasks, projects, meetings and opportunities. Read in full on every sync.Table: custom_fields · Primary key: id · Sync: Full table
Ticket forms and their fields. Read in full on every sync.Table: ticket_forms · Primary key: id · Sync: Full table
Macros (saved replies, notes and actions). Read in full on every sync.Table: macros · Primary key: id · Sync: Full table
Knowledge bases (help centers). Read in full on every sync.Table: knowledge_bases · Primary key: id · Sync: Full table
Articles of every knowledge base, in its default language, with draft and published content. Read in full on every sync.Table: knowledge_base_articles · Primary key: knowledge_base_id, id · Sync: Full table
Audit log of actions taken in your workspace. Synced incrementally by the time of the action.Table: audit_logs · Primary key: id · Sync: Incremental · Replication key: action_happened_at

Implementation notes

  • Incremental sync. Issues, tasks, projects and milestones are read by their last update time, audit logs by the time of the action. Each sync reads again from one hour before the latest update it saw, so late updates are not missed; records read twice are deduplicated.
  • Issue messages. Whenever an issue changes or gets a new message, all of its messages are read again, so edits and reactions are kept current.
  • Full table streams are read in full on every sync. If one that had records suddenly comes back empty, that stream fails instead of emptying your table, and its table keeps its data; run a full sync of the source if the data really was removed in Pylon.
  • Permissions. If the token’s role cannot read a stream you selected, that stream fails with a message naming it, and the other streams still load. Give the token a role with access, or deselect that stream.
  • Audit logs are not selected by default, because reading them usually needs an Admin-level token. Entries Pylon records more than an hour after the action are only picked up by a full sync.
  • Deleted or edited messages. Message changes are picked up when their issue is read again. A message deleted in Pylon stays in the issue_messages table.
  • File links. file_urls and attachment_urls are signed links that do not expire and open without signing in. Treat these columns as sensitive.