A few folks have been understandably frustrated by Granola's built-in limit of 10 exports per month on the Standard tier. While I always recommend reviewing your plan if export volume is a consistent need, I stumbled upon a useful workaround for occasional, larger one-off analyses.
It turns out the limit is enforced per *file download*, not per data query. The Granola UI bundles your selected metrics into one file when you hit "export." However, if you use the "Copy as CSV" function available in most data tables, you can manually reconstruct a larger dataset. You simply select and copy the visible rows, paste them into a spreadsheet, and then paginate through your results (using the 'next 100' or similar controls), repeating the copy-paste process each time. You can compile a dataset far exceeding the single-export file size limit.
This is clearly a manual process and not ideal for regular workflows, but for that quarterly report where you need to stitch together 15 segments of data, it can be a lifesaver. It's a good reminder to check for alternative data access points within a tool's interface. Has anyone else found similar creative solutions for temporary data needs within platform limits?
Keep it real, keep it kind.
Clever, but calling this a "workaround" is a bit generous. You're describing manual data entry. For a quarterly report, the time spent copy-pasting and validating that you didn't miss a row or page is a fantastic way to introduce human error.
More importantly, this highlights a control gap. If the vendor's limit is so trivial to bypass, even manually, what does the limit actually secure? It feels less like a technical constraint and more like a pure billing trigger, which is fine, but they should just say that.
Trust but verify
You're right that it's manual, but calling it 'data entry' undersells the technique. The point is it uses the tool's own structured output from a table, not manual transcription. You're still copying machine-generated rows.
Where this becomes more than a billing workaround is in regulated environments. If an auditor requests a specific dataset that would breach your contractual export limit, this method provides a documented, reproducible path to obtain it without violating the license agreement. You're not breaking a technical barrier, you're using an alternate, permitted output channel.
That said, I'd never architect a regular process around it. The validation overhead and risk of missing a pagination step are real. It's strictly a tactical, occasional method for when the formal export function is the wrong tool for the job.
Mike
That's a good point about the audit trail. Even if it's clunky, having a method that's technically within the bounds of the interface could matter more than efficiency in those cases.
I'm curious, though - wouldn't the act of manually paginating and compiling still introduce a risk of omitting data? You'd have to document each page's selection and paste operation to call it truly reproducible for an auditor.
The manual pagination and copy-paste method you've described is functionally a stateful cursor operation performed by a human. This highlights why the underlying API should ideally offer a cursor-based endpoint for large datasets, even if the UI doesn't expose a bulk export.
You're trading technical efficiency for contractual compliance, which can be a valid trade-off. For the audit trail mentioned later, you could supplement the manual process by logging the HTTP requests (viewable in browser dev tools) made for each page, as they would contain the timestamps and query parameters used. That creates a system-generated audit log of the data selection process itself.
sub-100ms or bust
Love this pragmatic approach. I've definitely used the "copy table" trick in a few different consoles when I needed a quick data pull for a one-off cost attribution query. It's not scalable, but it feels like a little victory when it works.
The key caveat I'd add is to double-check the CSV formatting when you paste. Sometimes the copy includes hidden formatting or extra headers that can really mess up your pivot tables later on. A quick `sed` or find/replace in a text editor before the spreadsheet can save a headache.
cost first, then scale