Integrations
Chip builds against the systems your team already works in. Connect one & its records land in Waypoint as ordinary tables, so when you ask for a dashboard over your open cases or an alert on contracts about to lapse, the data is already there.
What Waypoint connects to
| System | Read | Write | Real-time | What teams build on it |
|---|---|---|---|---|
| Jira Cloud | ✓ | ✓ | ✓ | Triage boards, escalation dashboards, automations that comment, transition & close |
| Jira Data Center | ✓ | ✓ | ✓ | The same, behind your firewall, from one workflow that runs against either deployment |
| Salesforce | ✓ | ✓ | ✓ | Case digests, renewal alerts, write-backs the account team sees in the record |
| ServiceNow | ✓ | ✓ | ✓ | Incidents, change requests & your own tables, with work notes kept off the requester's view |
| Slack | ✓ | ✓ | ✓ | Morning summaries, approval prompts, slash commands that start a workflow |
| Microsoft 365 | ✓ | ✓ | ✓ | Mail & SharePoint as a source, reports sent from your own domain |
| Intercom | ✓ | ✓ | ✓ | The whole conversation workflow: reply, note, tag, assign & close, US or EU |
| GitHub | ✓ | ✓ | ✓ | Issues, comments & labels kept in step with support |
| GitLab | ✓ | Planned | Planned | Merge requests, review threads, project activity & membership, self-managed included |
| Zendesk | ✓ | Planned | ✓ | Tickets, comments & attachments as context, with a new comment able to start a workflow |
| Confluence | ✓ | Planned | Planned | Your knowledge base, searchable by every agent |
| Notion | ✓ | Planned | Planned | Workspace pages as a source |
| Planned | ✓ | Planned | Scheduled digests & alerts with HTML templates, attachments & CC | |
| Anything that can POST | Planned | Planned | ✓ | Any system that can call an authenticated URL starts a workflow, with your JSON carried through |
| Any REST API | ✓ | ✓ | Planned | Systems not listed yet, reached over HTTP with an allowlist we set up with you |
Connect once, then build
There is nothing to build for the sync itself. When an administrator connects a system, Waypoint mirrors its records into synced tables inside your workspace, one row per source record, kept current on every sync. From then on they behave like any other table: put a list over them, chart them, filter them, join them to something you made by hand or point an automation at them.
So the request that gets you a dashboard over your cases is simply:
Give me a board of our open cases by stage, with owner & age, so I can see what's stalled.
Chip finds the mirrored table & builds on it. Connecting was the administrator's job & it happened once.
Connecting is mostly our side of the work. Waypoint installs its own app into Jira, sets up the rule that streams ServiceNow incidents & comments, & registers its own Zendesk webhooks. Your administrator authorises each one. Nobody writes integration glue.
What crossing systems looks like
Most useful requests touch more than one system, & you do not have to say how:
Every morning at 8, post to #support a summary of cases that breached SLA overnight, grouped by account.
When a contract in our tracker is 30 days from expiring, comment on the renewal ticket & email the account owner.
When a customer replies on an escalation, check whether the linked issue moved, & tell the engineer if it didn't.
Chip reads what is connected, picks the systems it needs & shows you the plan, including what it will touch, before it builds. Automations start switched off. You switch them on.
Where the work shows up
The systems above are where your team already works, so the work can show up there too.
A button in the ticket your agents already have open. A workflow can add a one-click action to the Salesforce case view or the Jira issue view, with its own confirm prompt. Nobody changes tools to run it.
Approvals in Slack, mid-run. A workflow can stop, post the decision to a person with buttons on it, wait, & carry on with the answer.
Slash commands your team defines. /chip followed by a command runs whichever workflow you gave that command. Your team adds one by building one.
Mail from your own mailbox. A workflow can read an incoming email & reply in thread from your own address. Who it may reply to is fixed by whoever built the workflow.
One workflow, more than one way in. The same digest can run on Monday morning & on demand when someone asks for it, with one copy to maintain.
Adding a system that isn't listed
The list above is what is connected today, and three routes take it further.
Anything that can call a URL can start a workflow now. A workflow can expose an authenticated web address that carries your JSON straight through to the steps behind it. If your system can POST when something happens, Waypoint can act on it. Nothing to build on our side.
Reach out over HTTP. For a system we do not list yet, a workflow can call its API against an allowlist of domains that we set up with you, with limits we set with you.
Ask us for a connector. A first-class connector, with mirrored tables & change detection, is a small addition on our side: the sync, change detection, retries & delivery are shared by every connector we run. The Salesforce connector shows the shape of it: it replicates any object your org can query, custom objects included, straight from your org's own description of itself.
That is why "do you support X?" usually gets a date. Tell us what you run & we will tell you what it takes.
See it built
- A morning summary for every team lead: one job, one Slack post per team.
- Contract renewal alerts: a daily job that emails the account owner.
- Draft and approve outreach: Chip drafts, a person approves, then it sends.
- Instantly modify existing views: Chip reads the screen you already have & rebuilds it in place.