Integrations
Bind a workspace Integration into a Project so your Runbooks and conversations can use it. There are two paths depending on the Integration: pick from a credential someone else created, or connect one yourself.
Audience: builders
The two paths
Pick from an existing credential. When IT (or another builder) has already connected the Integration, pick the credential from the list and bind it to your Project. No OAuth dance for you. Common for SharePoint, GitHub at the org level, large Drive accounts, and any admin-only API key Integration like Ramp or Stripe.
Connect one yourself. When the Integration supports self-serve OAuth or the org-level foundation is already in place, you can OAuth your own account from inside the Project. Common for Linear, Gmail, Slack workspace channels, and personal Drive folders.
Which path applies for a given provider is named on that provider's setup page. Visit Integrations and pick the provider. If the Integration is self-serve OAuth or admin-enabled OAuth with stage 1 already done, you can self-serve. Otherwise file a request with IT.
What each capability brings to the Project
Once an Integration is bound, your Project can use any of the Integration's lit capabilities:
- Read. Your Runbook or chat can read content from the Integration.
- Write. Your Runbook can save content back to the Integration.
- Triggers. The Integration can kick off a work item for your App. Configured under Apps > Triggers.
- Reply. Your agent can send messages back through the Integration (such as Slack thread replies).
The set of lit capabilities is provider-defined, not per-Project. A binding cannot grant a capability the Integration does not support.
What this article will cover
- Picking from an existing credential in the binding picker
- Self-serve OAuth from within the Project
- What an Integration exposes inside the Project once bound
- Calling an Integration from a Runbook or chat
- Sync status visible inside the Project
- When to ask IT for a credential and how to request one