Send Tally responses to Google Sheets: native integration and reconciliation

Decide whether the native connection is enough

If the requirement is simply to send form responses to one spreadsheet, evaluate Tally's native integration first. Branching, cross-service writes or custom reconciliation may justify Make. Publishing a form does not inherently require an additional automation platform. Define success as correspondence between accepted submissions and destination rows, not merely a connected-account indicator.

Choose the owning account and destination

Create a practice spreadsheet and confirm its Google account and collaborators. If a personal account owns the file, plan how ownership and authorization will be handled during staff changes. Response text and uploaded-file links may be included, so scope viewing access before turning on the integration. A shared reporting sheet should not casually expose everything collected by the form.

Connect from the Integrations tab

On the published form, open Integrations, connect Google Sheets, authorize the intended Google account and select the spreadsheet and sheet. Give the connection a name that identifies its form and purpose. Inspect existing connections so the same answer is not written into one ledger through two independent routes. Record which connection owns the destination write.

Choose historical export deliberately

Inspect the Export existing submissions option and decide whether earlier responses should be included. Tally documents historical export, but the actual selected option matters. If staff already copied earlier answers manually, reconcile their submission identities before enabling another import. A new connection should not be treated as new-responses-only without checking its settings and resulting rows.

Compare columns and timestamps

Submit one practice response and compare the source with the spreadsheet. Check the enquiry category, Japanese characters, multiline messages and the location of each field. Identify how timestamps are represented and align the spreadsheet's locale and timezone settings with the team's reporting needs. If file URLs are present, check who can access them from the shared sheet as well.

Recheck after edits or interruption

After changing a question or option, inspect where the new response is stored. Confirm current documented behavior for moved or removed columns and check that manual notes or formulas remain usable. When synchronization stops, compare source submissions with stored IDs and timestamps to identify the missing range. Avoid requesting another submission until you know whether the original still exists upstream.

Keep one owner for each destination write

If the native integration writes the spreadsheet row, Make should not add that same row again. It can handle a subsequent notification or classification instead. Replacing the native connection needs an explicit cutover point and historical recovery policy. Check overlap while both routes are active. Accepted submission, stored row and operator notification remain separate outcomes that need separate reconciliation.

• Build a Tally contact form: questions, publishing and checking submissions
• Send Google Forms responses to Slack with Make and Google Sheets
• Prevent duplicate writes in Make with stable keys and recovery states