> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/project-management/canny/best-practices.md). # Best Practices ## Recommended setup


Start with Posts as your anchor entity	The Posts entity contains the most joined-up data — vote count, status, board, author, tags, and score in a single table. Build your first analysis here before adding other entities.
Join Posts with Companies to weight by revenue	Use Coupler.io's Join transformation to combine Posts and Votes with Companies on company_id. This lets you see which features matter most to your highest-value customers, especially if you pass monthly_spend to Canny.
Use Status changes for pipeline reporting	The Status changes entity gives you a full audit trail of how posts moved through your workflow. Join it with Posts to calculate average time-in-status and surface where requests stall.
Append data from multiple Canny workspaces	If your organization has more than one Canny workspace (e.g., separate boards per product line), use Coupler.io's Append transformation to combine Posts or Votes from all workspaces into a single dataset.

## Data refresh and scheduling


Daily syncs are enough for most teams	Canny feedback doesn't change by the minute. A daily refresh keeps your dashboards current without hammering the API. Reserve more frequent syncs for active launch periods when post status changes rapidly.
Sync Status changes separately from Posts	Status changes is a high-volume entity on active boards. Running it in its own data flow lets you control its refresh cadence independently and keeps run times predictable.

## Performance optimization


Pull only the entities you need	Each entity is a separate API call. If you only need post-level analysis, don't add Comments or Votes to the same data flow — keep the scope tight to stay within rate limits.
Use BigQuery for large Canny datasets	If you have thousands of posts, votes, or comments, send data to BigQuery rather than Google Sheets. Sheets has row limits and slows down with large datasets, while BigQuery handles joins across entities at scale.

## Common pitfalls {% hint style="danger" %} Don't rely on the `score` field for straightforward vote-based ranking. Canny's score is a proprietary weighted value — if your stakeholders expect "most votes = highest score," use `vote_count` instead to avoid confusion in reports. {% endhint %} {% columns %} {% column %} **Do** * Join Posts with Companies to segment feedback by customer tier * Use Status changes to measure how long requests sit in each stage * Test your API key with the Posts entity first to confirm access before building complex data flows * Send Posts data to an AI destination like Claude or ChatGPT to generate a prioritized feature summary {% endcolumn %} {% column %} **Don't** * Assume empty fields like `monthly_spend` are a Coupler.io issue — check whether the data exists in Canny first * Export all 10 entities in a single data flow if your board is large — split by entity to avoid rate limit errors * Use the Votes entity as your only signal — one power user voting on everything skews raw vote counts {% endcolumn %} {% endcolumns %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.coupler.io/sources/category/project-management/canny/best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.