Docs

Documentation

Connecting your tools

A meeting is only useful once it becomes a task, a page or a record somewhere your team already works. Here is what setting that up actually involves — which is less than you would expect for about half of them.

Three kinds of setup, and yours is probably the easy one

Every destination Jaha writes to falls into one of three groups, and they differ enormously in effort.

Microsoft destinations — Teams, Outlook, OneDrive, SharePoint, Planner — need no authorisation at all, because the consent your administrator gave at signup already covers them. Tools with an OAuth app need one button and a permission screen. A small number issue only API tokens, and for those somebody has to fetch one and paste it.

Connecting a tool never gives Jaha permission to write to it unprompted. A connection is a capability; a rule is the instruction. Nothing leaves a meeting until you have written the rule that sends it.

Microsoft tools: a button, and at most one choice

Jaha is already an application inside your Microsoft 365 tenant, running on the consent an administrator gave once. So connecting Teams, Outlook, OneDrive, SharePoint or Planner means pressing Connect. There is no second sign-in, no token, and no secret to handle.

Where a destination genuinely has to be chosen — whose OneDrive, which SharePoint site — Jaha asks Microsoft what exists in your tenant and offers you the list. You pick from real sites and real mailboxes rather than pasting a URL from memory, which is the difference between a connection that works and one that fails after a meeting.

If your administrator has not granted the permission needed to read that list, Jaha says which permission is missing and links to the page where it is granted, instead of showing an empty menu that looks like an empty tenant.

One-click tools

Slack, Google Drive and Docs, Notion, Jira, Linear and Zoho use OAuth: press Continue, sign in to that tool, approve the permissions it lists, and you are connected. Jaha never sees a password, and the access it holds is exactly what you saw on the approval screen.

The permissions are deliberately narrow. Google Drive, for example, requests only the ability to see and edit files the app itself created — Jaha cannot read the rest of your Drive, and the approval screen says so in Google’s words rather than ours.

Where a deployment has not configured a vendor’s OAuth application, the connect screen offers a pasted token instead of a dead end. It is a fallback, and the screen says which one you are using.

Tools that need a token pasted

HubSpot, Salesforce, Pipedrive, Asana, ClickUp, monday.com, Todoist, Trello, Confluence, Dropbox and Box issue API tokens. Somebody creates one in that tool and pastes it into Jaha, where it is stored encrypted and never displayed again.

The connect screen for each of these carries the exact path through that vendor’s settings, and a link to the vendor’s own current page for it. We deliberately do not reproduce their screenshots: their interfaces change, and a stale picture is worse than a precise sentence.

Two of these need more than a token and the screen asks for it: Atlassian sends a token together with the account email that owns it, and a Pipedrive token is bound to your company address rather than the generic one. Both are single fields, and both exist because a token alone silently fails.

Deciding what goes where

A rule says which meetings reach which destination: all of them, only meetings with a customer, only ones matching a keyword, only the ones you tag. One meeting can feed several destinations, and each rule can carry its own filter.

Where a destination has to be named — a channel, a project, a plan, a space — Jaha asks the connected tool for the list and lets you choose. Typing an identifier by hand is the mistake nothing catches until a delivery fails days later, so wherever the vendor exposes a list, the field is a menu.

CRM rules have one extra question worth reading twice: what to do when nobody in the meeting is a contact. Skipping is right for a team whose CRM records customer relationships; attaching to a named fallback is right for a team that wants every call logged. Both are legitimate, so Jaha asks rather than deciding, and colleagues are never written to a CRM whichever you choose.

What actually lands

A recap becomes whatever that tool is for: a task per action item, a page in a workspace, a message in a channel, or an activity on a CRM record. Not a link back to Jaha — the content itself, so it is useful to somebody who has never opened our product.

Your task tool
Renew SOC 2 evidence pack
Send revised pricing to Northwind Trading
Confirm UAT window with Priya
Update the onboarding runbook

One task per action item, with the owner Jaha heard on the call.

Your document workspace

Northwind Trading — quarterly review

Thursday 12 March, 14:00

Summary

العربية

The recap as a page, in the meeting’s own language — and translated for whoever else was in the room.

Your team channel

Northwind Trading — quarterly review

3 decisions4 action itemsFull recap

Posted as Jaha, in the channel the team already watches — no webhook to create.

Your CRM

Northwind Trading

Renewal · closing this quarter

Meeting logged · quarterly review

Matched on the two attendees who are contacts. Colleagues are never written to the CRM.

Attached to the record it belongs to — and skipped, not guessed, when the call was not with a customer.

Illustrations, not screenshots — the shape of what arrives, drawn rather than captured from a real workspace. Northwind Trading is a fictional company.

When something fails

Every delivery is recorded against its meeting: what was sent, where, when, and what the far end said. A failure names the cause in the vendor’s own words and says what to change — a project that does not exist, a token no longer accepted, a channel the app has not been added to.

Failed deliveries can be retried or resent once the cause is fixed, and nothing is silently dropped. If a rule has been failing, it says so on the connection rather than waiting for you to notice.

Developers wanting the delivery payloads, webhook signatures and the REST surface should read Connectors & API.

Did this page help?