How to Process FTP Order Files into BigCommerce and Monday

Build a scheduled Spojit workflow that pulls CSV order files from an FTP server, creates BigCommerce customers from each row, opens a Monday.com tracking item per file, and archives the file once it is done.

What This Integration Does

Many wholesale, EDI, and partner ordering systems still drop order data as CSV files onto an FTP server. This workflow lets Spojit pick those files up on a fixed schedule, turn the rows into real BigCommerce customer records, and keep a running operational log in Monday.com so your team can see at a glance which files were processed and how many records each one contained. Nobody has to log into the FTP server, open spreadsheets, or copy data by hand.

The workflow runs on a Schedule trigger. On each run it lists the FTP inbox folder, loops over every CSV file it finds, downloads and parses the file, creates one BigCommerce customer per row, creates a single Monday.com tracking item summarising that file, then moves (renames) the file into an archive folder so it is never picked up twice. Because archiving is the last step per file, a re-run only ever sees files that are still in the inbox, which makes the workflow naturally idempotent at the file level. If a run finds no new files, it finishes quietly with nothing to do.

Prerequisites

An FTP connection in Spojit with read and write access to the order folder, an inbox path (for example /orders/inbox), and an archive path (for example /orders/archive). See Adding a New Connection.
A BigCommerce connection with API credentials that allow creating customers.
A Monday.com connection, plus the numeric boardId of the board where tracking items should land. Use the Monday.com connector's list-boards tool once to find it if you are unsure.
A known CSV column layout for the order files. This tutorial assumes columns named email, first_name, last_name, and company.

Step 1: Trigger the workflow on a schedule

Add a Trigger node and set its type to Schedule. Schedule triggers use a 5-field Unix cron expression plus an IANA timezone. To run every weekday morning at 7am Sydney time, use:

0 7 * * 1-5
Australia/Sydney

You can attach multiple schedules to the same trigger if you want, for example, both a morning and an afternoon sweep. The trigger output is simply { scheduledAt }; the real work begins by reading the FTP folder in the next step. For a deeper walkthrough of cron fields, see Setting Up a Schedule Trigger.

Step 2: List the FTP inbox folder

Add a Connector node in Direct mode, choose the FTP connector, and select the list-directory tool. Set path to your inbox folder:

{ "path": "/orders/inbox" }

The tool returns data.entries, an array where each entry has name, type (file or directory), size, and modifiedAt. Name this node's output variable something clear like inbox so you can reference {{ inbox.data.entries }} downstream.

Step 3: Loop over each CSV file

Add a Loop node in ForEach mode and point it at the file list from the previous step:

{{ inbox.data.entries }}

Inside the loop you have access to the current entry (for example {{ file.name }} and {{ file.type }}). If your inbox can contain folders or non-CSV files, add a Condition node as the first node in the loop body that only continues when the entry is a file whose name ends in .csv. Everything in the following steps runs once per matching file. See Using Loop Nodes for the iteration variables.

Step 4: Download and parse the file

Inside the loop, add an FTP Connector node in Direct mode with the download-file tool. Build the path from the inbox folder plus the current file name, and keep the default utf8 encoding since CSV is text:

{
  "path": "/orders/inbox/{{ file.name }}",
  "encoding": "utf8"
}

The output exposes the file body at data.content. Next, add a Connector node in Direct mode using the CSV Tools connector's parse tool, and feed it that text. parse converts the CSV into an array of row objects keyed by your header names, giving you fields like email and first_name to map later. Name this output rows.

Step 5: Create a BigCommerce customer per row

Add a nested Loop node (ForEach) over the parsed rows, for example, {{ rows.data }}, depending on how your CSV Tools output is shaped. Inside it, add a BigCommerce Connector node in Direct mode and select the create-customer tool. The create-customer tool takes a customers array, so map each row into a single customer object:

{
  "customers": [
    {
      "email": "{{ row.email }}",
      "first_name": "{{ row.first_name }}",
      "last_name": "{{ row.last_name }}",
      "company": "{{ row.company }}"
    }
  ]
}

Use a Transform node before this step if your CSV headers do not already match BigCommerce field names, so that the mapping stays clean. If you prefer to submit all rows in one call, you can also build the full customers array in a Transform node and call create-customer once per file instead of once per row.

Step 6: Create a Monday.com tracking item for the file

Back in the file-level loop (after the per-row loop completes), add a Monday.com Connector node in Direct mode and select the create-item tool. Use the file name as the item name and pass any board column values keyed by column ID through columnValues:

{
  "boardId": "1234567890",
  "name": "{{ file.name }}",
  "columnValues": {
    "status": { "label": "Imported" },
    "numbers": "{{ rows.data.length }}"
  }
}

Replace boardId with your real board ID and the column keys with the column IDs from your board. This leaves one row in Monday.com per processed file, which becomes your audit trail. To add a longer note, follow with the create-update tool against the new item.

Step 7: Archive the processed file

As the final step inside the file-level loop, add an FTP Connector node in Direct mode using the rename tool to move the file out of the inbox and into the archive folder:

{
  "from": "/orders/inbox/{{ file.name }}",
  "to": "/orders/archive/{{ file.name }}"
}

Because the file leaves the inbox only after its customers and tracking item are created, a failed run leaves the file in place to be retried on the next schedule. Make sure the archive directory exists first: you can create it once manually, or add an FTP create-directory node at the top of the workflow.

Tips

Ask Miraxa, the intelligent layer across your automation, to scaffold this for you with a prompt like "Build a scheduled workflow that lists CSV files from FTP, loops over them, creates BigCommerce customers, opens a Monday item, then renames the file to an archive folder." Then fine-tune each node in the properties panel.
Keep order files reasonably small per drop. Looping over thousands of rows in a single run is slower and harder to debug than several smaller files.
If you only want to send one tracking summary regardless of row count, compute totals (such as {{ rows.data.length }}) in a Transform node and reference them in the Monday.com create-item call.
Use the CSV Tools dedupe or filter tools before the customer loop to drop blank rows or duplicate emails so BigCommerce does not reject them.

Common Pitfalls

Forgetting to archive: if the rename step is missing or runs before customer creation, the same file is reprocessed on the next schedule and you get duplicate BigCommerce customers.
Path typos: download-file and rename need full remote paths including the folder. A leading-slash mismatch is the most common reason a file "cannot be found."
Column ID confusion in Monday.com: columnValues are keyed by column ID, not by the human label shown in the board header. Pull the IDs from get-board if a value silently fails to set.
Timezone surprises: schedule cron runs in the IANA timezone you set on the trigger, not your browser's. Double-check it if a run fires an hour off.

Testing

Before turning the schedule on, drop a single small CSV with two or three rows into the inbox folder and run the workflow once from the designer. Confirm in BigCommerce that the customers were created, check that a Monday.com item appeared with the right name and count, and verify the file moved from /orders/inbox into /orders/archive. Open the run in Spojit's execution log to inspect each node's output if anything looks off, then widen the schedule once a clean end-to-end pass succeeds. See Monitoring Workflow Executions.