How to Route Google Forms Responses through a Jinba Workflow

Summary

• Four Google Forms actions cover the core workflow: GOOGLE_FORMS_CREATE_FORM, GOOGLE_FORMS_ADD_QUESTIONS, GOOGLE_FORMS_GET_FORM, and GOOGLE_FORMS_BATCH_UPDATE, all secured by GOOGLE_OAUTH_CREDENTIALS.
• GOOGLE_FORMS_GET_FORM returns only the response count and form structure, so you must link the form to Google Sheets to read individual submission content.
• Use the same Google account for the OAuth consent screen and Google Search Console domain verification to avoid the most common authentication failure.
• Structured form-routing can reduce time on routine operations by up to 75% and cut operational costs by up to 28%.
• For a production-ready form intake workflow, Jinba Flow provides these Google Forms actions, polling, and downstream routing in one governed platform.

Manual Google Forms processing follows a predictable pattern: a response arrives, someone opens a spreadsheet, copies the data, pastes it into another system, and hopes nothing breaks in transit. That process is error-prone by design. A workflow built on Jinba's Google Forms actions replaces it with a repeatable, auditable sequence that runs without manual intervention.

The approach uses four tools: GOOGLE_FORMS_CREATE_FORM, GOOGLE_FORMS_ADD_QUESTIONS, GOOGLE_FORMS_GET_FORM, and GOOGLE_FORMS_BATCH_UPDATE. Authenticating them requires GOOGLE_OAUTH_CREDENTIALS. Once a form exists and its response count is readable, every downstream action, including routing, document generation, and approvals, can be triggered programmatically.

This guide covers google forms automation end-to-end: OAuth setup, form creation, question configuration, response monitoring, and routing logic.

Prerequisite: Set Up Google OAuth

Every Jinba action that calls a Google service authenticates through GOOGLE_OAUTH_CREDENTIALS. Without it, no form tools execute.

OAuth setup is where most teams encounter unexpected friction. The most common failure has a specific cause: the domain used in the OAuth consent screen must be verified in Google Search Console under the exact same Google account that created the consent screen. Using a different account, even within the same organisation, causes verification to fail. This step is not optional and is not surfaced clearly in the standard OAuth documentation.

The setup sequence:

1. Create a project in Google Cloud Console.
2. Enable the Google Forms API under "APIs and Services."
3. Configure the OAuth consent screen. Set the application type and add the required scopes (forms.body and forms.responses.readonly).
4. Verify the domain in Google Search Console using the same Google account.
5. Generate a Client ID and Client Secret, then supply both to GOOGLE_OAUTH_CREDENTIALS in Jinba.

Once credentials are confirmed, the remaining tools have access to the Forms API.

Step 1: Create the Form

GOOGLE_FORMS_CREATE_FORM creates a new Google Form via the Google Forms API. It takes two parameters:

• title (string, required): The name of the form.
• description (string, optional): A short description displayed at the top of the form.

To create a vendor contract intake form:

GOOGLE_FORMS_CREATE_FORM
title: "New Vendor Contract Request"
description: "Submit this form to initiate a new vendor contract review."

The action returns a formId. Store this value. Every subsequent action in the workflow references it.

Step 2: Add Questions

GOOGLE_FORMS_ADD_QUESTIONS populates the form with structured fields. The supported question types include:

• multiple_choice
• text (short and paragraph)
• checkboxes
• dropdown
• scale

Each question requires a title, a type, and, where applicable, a list of options. To add the core fields to the vendor contract form:

GOOGLE_FORMS_ADD_QUESTIONS
formId: "{{formId}}"
questions:
- title: "Vendor Name"
type: text
required: true
- title: "Contract Value (USD)"
type: text
required: true
- title: "Contract Category"
type: multiple_choice
options: ["Software", "Services", "Hardware", "Consulting"]
required: true
- title: "Requires Legal Review?"
type: multiple_choice
options: ["Yes", "No"]
required: true
- title: "Supporting Documents Attached?"
type: checkboxes
options: ["Purchase Order", "Scope of Work", "NDA"]

The form is now live and accepts submissions. The formId links it to every downstream action.

Step 3: Monitor for New Responses

GOOGLE_FORMS_GET_FORM reads the current state of the form. It returns:

• The form's full structure (title, questions, item IDs)
• The current response_count

It does not return a list of individual responses. There is no streaming action and no response-content retrieval through this tool. Teams that expect to read response data directly from this action will need to adjust their architecture: the form must be linked to a Google Sheet, and response content is read from the Sheet, not from GOOGLE_FORMS_GET_FORM.

What the response count enables is detection. By polling GOOGLE_FORMS_GET_FORM at a scheduled interval and comparing the returned response_count to a stored baseline, the workflow identifies when a new submission has arrived. That count increase is the trigger.

GOOGLE_FORMS_GET_FORM
formId: "{{formId}}"

Returns:

{
"title": "New Vendor Contract Request",
"response_count": 14,
"items": [...]
}

If the workflow stored 13 from the previous run, the difference of 1 signals a new submission. The workflow then proceeds to the routing logic using the linked Google Sheet row as the data source.

Step 4: Edit the Form with Batch Update

GOOGLE_FORMS_BATCH_UPDATE applies multiple structural changes to an existing form in a single API call. Use it when business requirements change: adding a new question, updating a dropdown list, reordering sections, or changing a required field flag.

For the vendor contract example, a single batch update could add a new "Preferred Contract Start Date" field and update the "Contract Category" options to include "Maintenance":

GOOGLE_FORMS_BATCH_UPDATE
formId: "{{formId}}"
requests:
- createItem:
item:
title: "Preferred Contract Start Date"
questionItem:
question:
required: true
textQuestion: {}
location:
index: 5
- updateItem:
item:
itemId: "{{categoryItemId}}"
title: "Contract Category"
questionItem:
question:
choiceQuestion:
options:
- value: "Software"
- value: "Services"
- value: "Hardware"
- value: "Consulting"
- value: "Maintenance"

Full request schema is documented in the Google Forms API guides.

Step 5: Route Responses through the Workflow

Once GOOGLE_FORMS_GET_FORM detects a count increase, the workflow reads the new submission from the linked Google Sheet and applies routing logic. This is where google forms automation moves from data collection to active process management.

A conditional branch evaluates the submission fields:

• If "Contract Value" exceeds $10,000, the workflow routes to the legal review path.
• If "Requires Legal Review?" is "Yes" regardless of value, the legal path is also triggered.
• All other submissions route directly to the finance approval path.

According to Zenphi, organisations applying this kind of structured routing to form submissions have reduced time on routine operations by up to 75% and cut operational costs by up to 28%.

Each routing path follows the same structural pattern:

1. Generate a document. A Google Docs template is populated with vendor name, contract value, category, and supporting document checklist from the form submission. No copy-pasting.
2. Send for approval. The document is routed to the relevant department manager via Gmail. A single-click approval or rejection triggers the next step.
3. Collect e-signature. Upon approval, the document is sent to the vendor via an integrated e-signature tool such as DocuSign.
4. Archive. The signed contract is moved to the "Signed Contracts" folder in Google Drive. A notification is sent to the finance team confirming the action.

This is the complete vendor contract workflow: form submission detected, data read from Sheets, document generated, routed for approval, signed, and archived, with no manual steps between submission and storage.

What to Watch for Next

The workflow described here handles creation, monitoring, and routing. Three areas merit early attention when teams extend it.

Response volume and polling frequency. GOOGLE_FORMS_GET_FORM returns a count, not a queue. If the workflow polls every five minutes and three responses arrive in that window, the count increases by three. The workflow detects a change but processes a single Sheet row unless the routing logic is written to handle batch deltas. Set polling frequency based on expected submission volume.

Sheet linkage is required for response content. The Forms API does not expose response field values through GOOGLE_FORMS_GET_FORM. The form must have a Google Sheets destination configured in the form settings before the first submission arrives. If responses are not linked to a Sheet at the time of submission, they are not retroactively written.

Scope selection determines what the workflow can read. The forms.responses.readonly scope grants access to response metadata through direct API calls. The forms.body scope covers form structure. Both are needed for a complete read-and-route implementation. Omitting either scope at the OAuth configuration stage produces authentication errors that surface only at runtime.

For teams building more complex integrations, Make.com's Google Forms integration offers a reference point for how other platforms structure trigger-based routing between Forms and downstream tools such as Notion, Trello, and Slack.

The Jinba workflow pattern is consistent: authenticate once with GOOGLE_OAUTH_CREDENTIALS, create and configure the form with GOOGLE_FORMS_CREATE_FORM and GOOGLE_FORMS_ADD_QUESTIONS, monitor with GOOGLE_FORMS_GET_FORM, update structure as needed with GOOGLE_FORMS_BATCH_UPDATE, and route on count change. Each tool has a defined scope. Combining them in sequence produces a workflow that requires no manual steps between a form submission and its downstream outcome.

FAQ

Can Jinba read individual Google Forms responses directly?

No. GOOGLE_FORMS_GET_FORM returns the response count and form structure, not individual response content. To read submissions, link the form to Google Sheets and read the new rows from the Sheet after detecting a response count increase.

What Google OAuth scopes are required for Jinba Google Forms automation?

You need both forms.body and forms.responses.readonly. forms.body lets you create and update form structure; forms.responses.readonly grants access to response metadata such as response_count. Missing either scope produces runtime authentication errors.

How do I set up Google OAuth for Jinba without domain verification errors?

Use the same Google account for the OAuth consent screen and Google Search Console domain verification. Create the project, enable the Forms API, configure the consent screen with the required scopes, verify the domain in Search Console, then generate the Client ID and Client Secret.

How can I trigger a Jinba workflow when a new Google Form response arrives?

Poll GOOGLE_FORMS_GET_FORM on a schedule and store the previous response_count. When the count increases, treat the delta as new submissions and continue with routing logic using the new rows from the linked Google Sheet.

What question types can I add with Jinba’s GOOGLE_FORMS_ADD_QUESTIONS?

Supported types include multiple_choice, text (short and paragraph), checkboxes, dropdown, and scale. Each question can have a title, type, required flag, and options where applicable.

Can I update an existing Google Form with Jinba?

Yes. Use GOOGLE_FORMS_BATCH_UPDATE to apply structural changes such as adding new questions, updating dropdown options, reordering items, or changing required fields in a single API call.

Do I need Google Sheets to automate Google Forms with Jinba?

For response content, yes. The Forms API does not expose individual response field values through GOOGLE_FORMS_GET_FORM. Configure a Sheets destination in the form before collecting responses so each submission is written to a new row.