How to Export MongoDB Collections to CSV on FTP Weekly

Build a Spojit workflow that runs on a weekly schedule, reads documents from a MongoDB collection, converts them to a CSV file, and uploads the file to an FTP server for partner delivery.

What This Integration Does

Many partners and downstream systems still expect a flat CSV file dropped onto an FTP server on a fixed cadence rather than a live API. This workflow closes that gap: every week, Spojit pulls a slice of records from a MongoDB collection, flattens them into a single CSV string, and writes that file to a partner's FTP directory with a dated filename. You get a hands-off, repeatable export that runs whether or not anyone is at their desk, and a clear execution history you can audit if a partner ever asks "did the file go out?".

The run model is fully scheduled. A Schedule trigger fires on a Unix cron expression in the timezone you choose, with no inbound request involved. Each run queries MongoDB with the find-documents tool, converts the returned documents to CSV in memory, and uploads the result with the FTP upload-file tool. Nothing is stored in Spojit between runs: the file lives on the FTP server, and the only persistent state is the execution log. Because the schedule simply fires again next week, a missed or failed run does not block the following one, and re-running the workflow manually produces a fresh export of whatever is in the collection at that moment.

Prerequisites

A MongoDB connection in Spojit (Connections -> Add connection -> MongoDB) pointed at the database that holds the collection you want to export. See the MongoDB connector article for setup.
An FTP connection in Spojit with write access to the destination directory, and the remote path your partner expects (for example /outbound/partner-a/). See the FTP/SFTP connector article.
The exact collection name and the set of fields you want in the CSV (the column order you will hand to the partner).
The IANA timezone the schedule should run in (for example Australia/Sydney) so the cron time lines up with your business hours.

Step 1: Add a Schedule trigger

Open the Workflow Designer, add a Trigger node, and set its type to Schedule. A Schedule trigger uses a 5-field Unix cron expression plus a timezone. For a weekly export at 6:00 AM every Monday, set the cron to 0 6 * * 1 and the timezone to your region, for example Australia/Sydney. A single trigger can hold multiple schedules, so you can add a second entry later if a partner wants a mid-week run too. The trigger output is { scheduledAt }, which you can reference downstream as {{ scheduledAt }} when naming the file.

Step 2: Read the collection from MongoDB

Add a Connector node in Direct mode, choose your MongoDB connection, and pick the find-documents tool. Set collection to the collection you are exporting. Use the filter field to limit the rows to just what the partner needs, the projection field to include only the columns you want, and sort plus limit to bound the result. For example, to export only active records updated in the trailing period, ordered newest first:

collection: orders
filter: { "status": "fulfilled" }
projection: { "orderId": 1, "customerEmail": 1, "total": 1, "fulfilledAt": 1, "_id": 0 }
sort: { "fulfilledAt": -1 }
limit: 5000

The tool returns { success, data: { documents, count } }. Name the node output something like mongo so you can reference the array as {{ mongo.data.documents }} and the row count as {{ mongo.data.count }} in later steps. Direct mode is the right choice here because this is a single, predictable query with no AI cost.

Step 3: Guard against an empty result

Add a Condition node so you do not upload an empty or header-only file when the query returns nothing. Set the condition to check that {{ mongo.data.count }} is greater than 0. Route the true branch into the CSV conversion in the next step. Leave the false branch unconnected (or send it to a Send Email node that notifies your team that there was nothing to export this week). This keeps partner directories clean and makes "no data" an explicit, visible outcome in the execution log rather than a silent zero-byte upload.

Step 4: Convert the documents to CSV

On the true branch, add a Connector node in Direct mode, choose the built-in CSV utility connector, and pick the from-json tool. Map data to {{ mongo.data.documents }}. Use the columns field to pin the exact column order your partner expects (otherwise the keys of the first document are used), keep header set to true, and leave delimiter as ,:

data: {{ mongo.data.documents }}
columns: [ "orderId", "customerEmail", "total", "fulfilledAt" ]
header: true
delimiter: ","

The tool returns a csv string and a rows count. Name this node output csvFile so the rendered file is available as {{ csvFile.csv }}. Because MongoDB documents can contain nested objects, use a Transform node or the JSON utility connector's flatten tool before this step if your records are not already flat: from-json expects an array of flat objects, one row per object.

Step 5: Build a dated filename

Add a Connector node in Direct mode, choose the built-in Date utility connector, and pick the format tool to turn the run time into a stable date stamp. Feed it {{ scheduledAt }} and a format such as YYYY-MM-DD, then name the output stamp. This gives you a non-colliding filename per run, which matters because the FTP upload-file tool overwrites a file if the same path already exists. A weekly file path then looks like /outbound/partner-a/orders-{{ stamp.result }}.csv. Using a date instead of a fixed name means each week's export lands as its own file the partner can pick up and archive.

Step 6: Upload the CSV to the FTP server

Add a final Connector node in Direct mode, choose your FTP connection, and pick the upload-file tool. Set path to the dated remote path, set content to the rendered CSV, and leave encoding as utf8 since CSV is text:

path: /outbound/partner-a/orders-{{ stamp.result }}.csv
content: {{ csvFile.csv }}
encoding: utf8

The tool returns { success, data: { path, size, message } }, so you can confirm the byte count with {{ upload.data.size }}. Optionally add a Send Email node after the upload to email your operations team a one-line confirmation that the weekly file was delivered, including the path and the row count {{ csvFile.rows }}. Save the workflow, then enable it so the schedule starts firing.

Tips

Keep the MongoDB limit realistic for a single file. If a partner export can run to tens of thousands of rows, page through the data with the skip field across a Loop node, or pre-aggregate with the aggregate tool so each run handles a bounded slice.
Pin the column list in from-json rather than relying on document key order. MongoDB documents are schemaless, so a single record with an extra field can otherwise change your CSV's column layout between weeks.
If your partner needs the file under a fixed name (for example latest.csv), upload the dated file first, then add a second upload-file step writing the same content to the fixed path. upload-file overwrites, so the fixed name always reflects the newest export.
Ask Miraxa, the intelligent layer across your automation, to scaffold the chain for you. Try a prompt like "Add a CSV from-json node mapped to {{ mongo.data.documents }} and connect it to an FTP upload-file node", then fine-tune the fields in the properties panel.

Common Pitfalls

Timezone drift. Schedule cron runs in the IANA timezone you set, not the viewer's local time. A cron of 0 6 * * 1 with the wrong timezone can deliver the file hours early or late, so confirm the timezone matches the partner's expectation.
Nested documents in the CSV. The from-json tool expects flat objects. If a document contains a nested object or array, that column renders as serialized text. Flatten or project away nested fields before conversion.
Overwrites from a static filename. Because upload-file overwrites an existing path, a non-dated filename silently replaces last week's file. Use a date stamp in path if the partner expects to keep a history.
Wrong remote directory or no write access. If the FTP connection lacks write permission on the target directory, the upload fails the run. Verify the connection and that the directory exists before enabling the schedule (the FTP verify-connection tool is handy for a quick check).

Testing

Before enabling the weekly schedule, validate the whole chain on a small scope. Temporarily set a tight filter and a low limit (for example 5) on the find-documents step, point path at a test directory such as /outbound/test/, and run the workflow with the Run button rather than waiting for the cron. Open the execution log to confirm {{ mongo.data.count }}, the rendered {{ csvFile.csv }}, and the FTP {{ upload.data.size }} look right, then download the test file from the FTP server and open it to check the columns and row count. Once the file matches what your partner expects, restore the production filter, path, and limit, and enable the workflow so the Schedule trigger takes over.