Connect Dropbox to Google Drive with Make.com to upload rename and log assets automatically. Setup, field mapping, and reliability tips for workflows and audits.
Introduction
Moving media assets between cloud storage often starts as a simple habit. A file lands in Dropbox, someone renames it to reflect the client or project, and a teammate copies it into Google Drive for archiving or sharing. In practice this quickly becomes error prone. Files get renamed inconsistently, duplicates show up, and the audit trail is a mess. In this guide you will learn a practical Make.com pattern to watch a Dropbox folder, upload to Google Drive with a deterministic name, and log the action so you can track every asset movement.
By the end of this post you will know how to wire a lean two tool workflow that saves time and reduces risk. You will also see how this pattern fits into broader file and media workflows that Olmec Dynamics often builds for teams that manage marketing collateral, design assets, or client deliverables.
What you will need
- A Dropbox account with a folder to monitor for new files
- A Google Drive account with a destination folder for uploaded assets
- A Make.com account with connections to Dropbox, Google Drive, and optionally Google Sheets for an audit log
- A naming convention you want to apply to uploaded files, for example date-client-project or client-date-file type
Optional prerequisites:
- Basic familiarity with Make.com scenario building
- Paid Make.com plan if you anticipate production scale or complex routing
How it works (the logic)
Trigger: A new file appears in a watched Dropbox folder. Make reads the file information and proceeds to download the binary payload if needed.
Action: Make uploads the file to Google Drive using a deterministic file name. The name can be built from the original file name plus a date stamp, and can optionally include a client or project tag if you can extract it from the Dropbox metadata or from a separate mapping source.
Post-upload: Make renames the Drive file to reflect the final naming convention. If you cannot rename the Drive item directly, you can apply the naming at the upload step so the file lands with the correct name from the start. For long running pipelines you can also move the original Dropbox file to an Archive folder to avoid reprocessing.
Audit: You can log the event in a Google Sheet or a Notion table with fields for dropboxPath, drivePath, fileName, timestamp and status. Logging ensures you can prove what moved where and when.
Notifications: If you want, post a concise Slack message that a new asset moved, including a link to the Drive file and the original Dropbox path. This gives the team quick visibility without hunting through logs.
Step by step setup
- Create the Make.com scenario and set up a Dropbox trigger
- In Make.com create a new scenario named Dropbox to Drive rename and log.
- Add the Dropbox module Watch Files or Watch Folder. Point it to the folder you want to monitor.
- Turn on sample data so you can map fields like file name and file path.
- Add a Google Drive action to upload the file
- Add Google Drive module Upload a File.
- Choose the destination folder where uploaded assets should live.
- For the file name, compose a string that includes the original name plus a date stamp, for example 2026-10-08_Client_Project_originalName.ext.
- If you can access the file content from Dropbox, pass it as the file content payload to Drive.
- Rename the uploaded file on Drive (optional but recommended)
- Add Google Drive module Rename a File.
- Use the Drive file id returned by the Upload action as the target.
- Set the new name to the same naming convention you used during upload, or adjust the timestamp format to suit your needs.
- Archive the source in Dropbox (optional)
- Add a Dropbox move action to move the original file to an Archive subfolder. This prevents reprocesses when the scenario runs again and keeps your watched folder clean.
- Log the action in Google Sheets (optional but recommended)
- Add Google Sheets module Add a Row.
- Map fields such as Dropbox path, Drive path, final file name, timestamp, and a status field like Uploaded.
- Notify your team in Slack (optional)
- Add Slack module Post Message.
- Keep the message compact and include a link to the Drive file and the Dropbox folder path.
- Test and enable
- Upload a test file to Dropbox and verify the file lands in Drive with the right name and in the correct folder.
- Confirm the Drive path and the log row appear in Google Sheets if you enabled logging.
- Check Slack if you enabled the notification.
Real world scenario
A design studio uses this pattern to standardize asset handoffs from design to client sharing. A new asset lands in a Dropbox folder each time a designer finalizes a deliverable. The Make.com scenario copies it to Drive with a date-stamped name, archives the source, and logs the event. The team shares the Drive link in the client channel along with a summary. They now can locate any asset by date, client, or project with minimal digging.
Common variations
- Add metadata from Dropbox to the Drive filename by pulling metadata from an additional data source or a mapping table. This helps when you have multiple clients in a single folder.
- Extend the log with a Notion or Airtable table for cross-system asset tracking. A Notion page can host the latest version and a thumbnail preview.
- Use a scheduled check to clean up older assets in Drive or Archive folders, and notify the team when retention rules kick in.
Closing thoughts
This Dropbox to Google Drive automation pattern gives you a reliable, auditable way to move assets without manual renaming or duplicate copies. If you want similar file and media workflows for other platforms, Olmec Dynamics builds these patterns for teams that need robust file handling and clear traceability. Learn more about our approach to Cross-Platform Automation at the link below and reach out if you want a tailored setup for your stack.
For related patterns and deeper templates see the Cross-Platform Automation page and our content on PandaDoc and Airtable integrations, which illustrate how we structure these workflows to be maintainable across teams. You can learn more at Olmec Dynamics.