> 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/time-tracking/timetonic/best-practices.md). # Best Practices ## Recommended setup


Start with a filtered view	If your TimeTonic table is large, create or select a view that filters by date range, status (approved only), or project. This reduces export size and speeds up data flows.
Use meaningful column names	In TimeTonic, name custom fields and columns clearly (e.g., "Billable Hours" instead of "Field1"). Clear names make it easier to work with the data in your destination.
Set up a dedicated export table	If you frequently export TimeTonic data, create a table or view in TimeTonic specifically for exports. This isolates export logic from your working data and makes maintenance easier.
Document your API key securely	Store your TimeTonic API key in a password manager or secure vault. Never share it or commit it to version control. Regenerate it periodically for security.

## Data refresh and scheduling


Run manual tests before scheduling	Always complete a successful manual run of your data flow and verify the data in your destination before setting up a schedule. This confirms the connection, table selection, and data quality.
Schedule refreshes after payroll or billing cutoffs	If exporting for payroll or invoicing, schedule the data flow to run after your cutoff date. For example, run on the first of each month to capture the prior month's complete data.
Use hourly or daily refreshes for dashboards	If feeding Looker Studio or Google Sheets dashboards, use hourly or daily scheduled refreshes (depending on how current your data needs to be) to keep dashboards up-to-date without manual intervention.

## Performance optimization


Use views to pre-filter data	Instead of exporting all rows and filtering in your destination, use TimeTonic views to pre-filter (e.g., approved entries, current month). This reduces data transfer and processing time.
Export only the columns you need	If your TimeTonic table has many columns, configure the view to show only the columns you actually use. Fewer columns mean faster exports and smaller file sizes in your destination.
Break large exports into multiple flows	If exporting multiple years or thousands of rows, create separate data flows for different time periods or projects. Run them in parallel or on a staggered schedule to avoid timeouts.

## Common pitfalls {% columns %} {% column %} **Do** * Select the correct view upfront — verify filters and column selection match your needs * Test the connection with a small view before running full exports * Monitor the first few scheduled runs to confirm data quality * Use Append transformations to combine multiple months or teams into one table {% endcolumn %} {% column %} **Don't** * Export without testing — always run a manual test first and check the destination * Change your TimeTonic table structure without updating your view — this can break exports * Schedule refreshes too frequently for small data sets (hourly refreshes of 10 rows is wasteful) * Rely on draft or unapproved entries for payroll — always filter to approved status {% 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/time-tracking/timetonic/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.