BLOG
Google Forms, Drive, and an automation can organize documents by client when each submission is linked to the correct folder and the permissions are checked. The important result is not merely a folder appearing: it is the right files reaching the right location, with a traceable request and someone responsible for failures.
Define that path before implementing the script. Agree on the source, the client’s identity, the destination, and the evidence of completion. A response saying “submitted” establishes only that the form accepted an entry. It does not, by itself, establish that a later filing process completed.
Define client identity before folder creation
Use a stable internal identifier for the client and a separate identifier for each submission or request. A display name is not a dependable unique key: names can be spelled differently, and two clients can have the same name. The same client can also submit several legitimate requests.
A code typed into a public form should not automatically be trusted as proof of identity or authorization. Establish how it is issued and checked against your business records. If the mapping is uncertain, route the submission for review rather than moving documents into an existing client’s folder based on a guess.
Before adding automation, you can prepare the intake using our Google Forms guide. Decide whether file uploads belong in that first contact at all. Sometimes it is more appropriate to collect documents only after staff have assessed the request and confirmed the client.
Use the official sample as a starting point
Google provides an Apps Script sample for routing Forms uploads into Drive folders. It illustrates receiving a form event and moving uploaded files into a selected destination. Treat that sample as the foundation for an implementation, not a complete client-record management system.
The example uses an Apps Script project opened from the form. If you follow that route, keep the handler and trigger consistent with a Forms submission event. A project attached to the linked response spreadsheet receives a different event shape. Mixing the two approaches can make a seemingly reasonable field reference fail.
A response spreadsheet can still be used as an explicit mapping or processing register. That does not require pretending the handler is spreadsheet-bound. Decide which event starts the script, then access any additional register intentionally rather than relying on whichever file happens to be active.
Choose the correct installable trigger
Google’s installable-trigger guidance distinguishes Forms and Sheets submission triggers. For a form-bound implementation, create the installable form-submit trigger for the handler expected by that project. Read the received response using the documented Forms event structure; do not substitute spreadsheet event fields.
Installable triggers run with the authorization of the account that created them. Assign a business owner and confirm what that account can access. A customer submitting a file does not become the account running your filing script, and the script does not automatically gain permissions it was never granted.
During handover, record the project, handler, trigger, account, destination parent folder, and failure contact. Test the real submission path with authorized sample files. Calling a handler manually without the expected event object is not equivalent to a real form submission.
Keep a persistent folder and processing register
Maintain an explicit mapping from the approved client identifier to the Drive folder ID. For each submission, also record its processing state and file IDs. The table below is an example design, not a built-in schema automatically created by Google Forms.
| Field | Purpose | Check |
|---|---|---|
| client_id | Identify the approved client record | Match your controlled business record |
| folder_id | Reuse the correct destination | Verify the folder and its parent |
| submission_id | Recognize a repeat of one submission | Keep it separate from client identity |
| file_ids | Track the specific uploaded files | Preserve them for recovery |
| status | Distinguish pending, processing, completed, and failed work | Mark complete only after checking the destination |
Normalize the identifier according to a defined rule before lookup. Do not silently merge clients because their names or email addresses look similar. If there is no approved match, decide whether staff should create the client record first or review the submission in a holding area.
For a new approved client, create the folder under the intended parent and persist its ID before moving the remaining files. For an existing client, reuse the recorded ID and verify that the folder is still accessible. A folder’s visible name alone should not override the stored relationship.
Handle retries and simultaneous submissions deliberately
Before processing, check whether the submission has already completed. If it has, reuse the recorded outcome rather than creating another folder. If it stopped partway through, inspect the saved folder and file identifiers and resume only the unfinished steps. Do not treat every retry as a new business request.
Two executions can both look up a client before either has saved a folder. In an Apps Script implementation, LockService can protect an appropriate shared lookup-and-create section from concurrent execution within its scope. Choose that scope for your design; it is not a general lock across unrelated scripts or systems.
A lock does not make creating a Drive folder and writing a spreadsheet row one atomic transaction. If a failure happens between them, reconcile the partial result before creating again. A controlled parent and stable internal folder key can assist recovery, but multiple possible matches should go to review. Keep enough information to investigate a partially completed operation without relying on a name search across all of Drive.
Check permissions independently from file location
Moving files into the expected folder does not establish that access is correct. Review the parent folder’s sharing, inherited permissions, direct access, and relevant organization policy. Google’s Drive sharing guidance explains permissions and inheritance. Confirm the actual access needed rather than adding broad link sharing to solve a convenience problem.
Keep internal filing separate from sharing a folder with a client. A customer providing documents does not mean every member of your team, or every person with a link, should be able to read them. If external sharing is part of the process, require a verified recipient and a deliberate permission decision.
Test with a representative authorized account, not just the owner. The owner may be able to open files that a colleague cannot, while broad parent access may expose files more widely than intended. Test the boundary relevant to the workflow before describing the delivery as complete.
Make failures visible and recoverable
Record the submission identifier, approved client, folder ID, file IDs, outcome, and time. Define who sees a failure and how they take ownership. Avoid copying document contents or unnecessary personal information into logs merely to demonstrate that something ran.
Apps Script has execution and service quotas that depend on the service and account. A workflow that handles a few files is not automatically suitable for an unrestricted upload queue. Check the applicable limits and plan a way to identify work that remains pending when an execution stops.
Pause the affected process if documents reach the wrong client’s location. Investigate the identity mapping and permissions before retrying. For a simple access failure, retain the file and folder IDs so staff can correct authorization and resume without duplicating the entire filing operation.
Pilot with a small acceptance checklist
Test a new approved client, an existing client, an unknown identifier, a missing upload, a repeated event, and an unavailable destination. Include simultaneous submissions if the business expects them. Each test should have an expected destination and outcome written down beforehand.
- Verify the files at the destination, not just the execution log.
- Confirm the recorded folder ID belongs to the correct client and parent.
- Replay the same submission and check that it does not create another client folder.
- Review access with the account that actually needs to use the documents.
- Interrupt or simulate a failure in a controlled test and verify the recovery procedure.
Change one rule at a time and preserve the previous configuration. Name the person covering absence or staff turnover. A small operating note with the project owner, approved mapping, recovery steps, and last review date is more useful than an undocumented script only its author understands.
Frequently asked questions
Does Google Forms automatically create a folder for every client?
No. File-upload storage and a client-specific folder strategy are different things. The latter needs an implementation, permissions, identity rules, and testing. Do not assume the form’s default upload folder is already an organized client archive.
Which account runs the installable trigger?
The trigger runs under the account that created it, with the permissions that account has authorized. Document that ownership and check access when staff or business accounts change.
Is this worthwhile for a low-volume process?
Sometimes a manual checklist is enough. Automate when repeated filing justifies development and maintenance, and the team can verify the result. More sensitive documents or more complex access rules require more careful review, not merely more script steps.
Approve the complete filing outcome
The useful result is a traceable submission, an approved client match, the correct files and destination, and appropriate access. Start with one small workflow, test failure and repetition, and expand only after the team can operate and recover it. The same principles apply to broader business automation planning with tools such as n8n, even when the implementation uses Apps Script.
