Asana
What is it?
Sharely reads the Asana projects where your product work is planned, and treats a task as what was meant to ship.
That gives the product connectors the other half of the story. A merged pull request says what the code did; the task it references says what somebody intended. Sharely reads both, and says when they disagree.
What problems does it solve?
- "Done" in Asana is not done in the docs. A task moved to released is checked against your content the same way a merged pull request is, and gets its own report.
- Code alone does not say why. A diff shows what changed; the task says what it was for. Reports read better, and the agent can answer "what shipped this week" in product terms rather than commit titles.
- The plan and the code drift quietly. When a change references a task, Sharely compares what was planned with what the code actually did, and says so when they differ.
Requirements
- A Sharely.ai workspace, with a GitHub connection for the code side.
- Owner or admin of that workspace.
- An Asana account that can see the projects you want read, and permission to grant an app access to them.
Note: Pick the workspace in the sidebar before you start. An Asana connection belongs to one workspace.
How to connect it
- Go to Product → Connect and press Connect Asana.
- Approve the request in Asana. Sharely asks for read-only access to workspaces, projects, tasks, tags, custom fields and attachments, plus permission to manage its own webhooks on the projects you pick.
- Asana sends you back to the connection's settings.
- Choose the Asana workspace, if the account that granted access belongs to more than one. One connection reads one workspace.
- Pick the Projects to read, and for each one the section that means released.
How to set it up
Projects
Tasks in the projects you pick become work items — visible in Product → Work, and beside any code change that references them.
For each project, choose the section that means released. A task is treated as shipped when it is completed, or when it is moved into that section. Released wins when both are true, because it says more.
If your team ships by completing tasks rather than moving them, leave the released section unset; completion alone is enough.
Visibility
The roles that may see this connection's tasks, in Work and beside the changes that reference them. The same rule as GitHub: a person holding none of these roles sees none of it, and visitors to your public sites never hold them.
How work items stay current
| When a project is first picked | every task in it is read once |
| While you work | a webhook per project sends each change as it happens |
| Every night | a backstop re-reads anything modified since the last sync, in case a webhook was missed |
Asana webhooks are best-effort, which is why the nightly pass exists. A task edited while a sync is running is re-read rather than skipped.
What it produces
Work
Every work item, grouped by status, with the code changes matched to it and whether each shipped change was checked against your content.
A task is matched to code two ways: a asana:<id> reference in a branch name, pull request title, body or commit message, and the pull request links Asana's own GitHub app attaches to the task.
A report when a task ships
Marking a task released produces a report of its own, in product terms — what it changed for users, read from the task and from any code already matched to it.
This matters for work whose code is spread across several pull requests, lives in a repository nobody connected, or is internal: the task is the trigger, and its own words are enough when there is no diff to read. Reports resting on the task alone carry lower confidence, and say so.
A capability in the vocabulary
A report from a task names capabilities the same way a report from code does, so work that never produced a diff Sharely could read still reaches Capabilities and Coverage. See GitHub.
Intent on a code change
When a change references a task, the agent is given the task as the plan behind it — up to three per change. If the code visibly does something other than the task described, or leaves part of it out, the report says what was planned and what was observed.
Data and privacy
- Read-only. Sharely never writes a task, a comment or a field back to Asana. The only thing it creates is its own webhook on each project you pick, which it removes when you disconnect.
- Task text is treated like code. Titles, descriptions and custom field values pass through the same secret scanner as a diff, so a token pasted into a task is redacted before the agent reads it.
- Descriptions are capped at 4,000 characters.
- Tokens are encrypted before they are stored and are never sent to a browser.
When something does not appear
| What you see | Usually |
|---|---|
| No work items | no project is picked yet, or the account that granted access cannot see them |
| A task is there, no code beside it | nothing references it — no asana:<id> in a branch, title, body or commit, and no pull request attached in Asana |
| A completed task shows no report | it was judged not user-facing: internal work, a refactor, tooling or research |
| A released task is still shown as open | the released section is not set on that project, or the task was moved in a different one |
| Changes stopped arriving | the project's webhook was removed in Asana. The nightly sync still picks changes up, and re-picking the project recreates it |
| "Reconnect" on the connection | the grant was revoked in Asana. Connect it again |
Disconnect
Settings → Disconnect removes the webhooks and the stored access. Work items already read stay in the workspace, as do the reports written from them.
Learn more
- Product — how connections, changes, reports and gaps fit together.
- GitHub — the code side, which Asana work items are matched against.
- Jira — the same thing, if your team plans there instead.
- Slack — where what the connectors find gets posted.
- Integrations overview — the other ways to connect Sharely.ai.