e-satisfaction

Data bridges

A data bridge automates recipient imports. Instead of uploading a CSV by hand each time, you point a bridge at a file on a server — your own, or one e-satisfaction hosts for you — map its columns once, and set a schedule. From then on the bridge connects, reads the file, and turns each row into a queue item — with no one lifting a finger.

It's the right tool when your systems already export a recipient list regularly (nightly orders, weekly sign-ups, daily visits) and you want those people surveyed automatically.

How an automated import runs

Every time a bridge runs — on its schedule or when you trigger it — it follows the same four steps:

Connect

The bridge opens a connection to your server using the protocol and credentials you configured.

Read the file

It reads the file at the path you set. If the path contains date variables, they're resolved to the moment of the run, so each run can read that day's file.

Map and parse

It splits each row using your column separator and maps the columns to the fields a queue item needs.

Create queue items and log the run

Each valid row becomes one queue item in the pipeline, and the whole run is recorded in your import history.

Connecting to a server

A bridge's Server settings show which server it reads from, as a single panel:

  • Managed SFTP Server — the bridge uses your organization's e-satisfaction SFTP server.
  • External server — the bridge uses a server of your own. The panel shows its protocol, address and login, and Edit opens the connection fields.
  • No server yet — on a new bridge, choose Use managed SFTP server (when your organization has one) or Enter server details.

Your own server

Choose the protocol — SFTP (secure file transfer over SSH) or FTP — and, for SFTP, how the bridge signs in:

  • Username & password — the usual login.
  • Key file — an uploaded private key instead of a password. If the key is protected with a passphrase, enter it in the Key passphrase field; leave it blank if it isn't.

Then provide the host, the port and the username. For FTP you can also turn on passive mode if your network requires it. Click Done to fold the fields back into the summary.

Allow our IP addresses in your firewall

The bridge connects to your server from 207.154.250.203 and 68.183.76.178. If your server's firewall only accepts known addresses, allow both on the port you entered — otherwise Test connection, Check file and every run will fail to reach it. See External connections & IP allowlist.

Port 22 isn't supported

We block all outgoing connections on port 22 as a security measure. Port 22 is the usual SFTP port, so a server that only listens there can't be used as it is — the bridge form says so and won't save it.

The fix is on the server's side, and it doesn't stop anything else using port 22:

Add a second port

Ask whoever runs the server to have its SSH/SFTP service also listen on another port — for example 2222 (for OpenSSH, an extra Port 2222 line in sshd_config).

Open it in the firewall

Allow inbound connections on that port in the server's firewall.

Use it in the bridge

Enter the new port in the bridge's Server settings, then use Test connection and Check file.

A bridge saved on port 22 before this change keeps running on its schedule, but it can't be tested, checked or run by hand until its port is changed. The Data Bridges page tells you how many of your bridges are still on port 22 and marks each with a Port 22 — not supported chip; View and fix them lists just those, so you can open each one and change its port.

The e-satisfaction SFTP server already uses port 2222.

Why we block port 22

Port 22 is the standard port for SSH, the secure protocol SFTP runs on — and that makes it one of the most attacked ports on the internet. Automated bots scan every address around the clock and try to sign in with guessed, common or stolen passwords (so-called brute-force and credential-stuffing attacks). A server listening on port 22 typically sees such attempts within minutes of going online, and keeps seeing them for as long as it is up.

Blocking outgoing connections on port 22 from the platform that runs Survey Manager protects you — and everyone else on the internet — in three ways:

  • Our platform can't be turned into a weapon. When attackers gain a foothold on any server, one of the first things they do is use it to launch automated SSH attacks on other servers. With port 22 closed on the way out, that can't be done from ours, even in the unlikely event that something inside it were compromised.
  • Data can't quietly leave. SSH on port 22 is also the standard route for copying data out of a compromised system. Closing it means data can leave only through the connections we build on purpose, check and log.
  • It is established security practice. Allowing an application to make only the outgoing connections it actually needs — known as outbound (egress) filtering — is a core part of zero-trust and data-loss-prevention security.

Keeping your own server safe

A different port cuts out most of the automated noise, but a port number is not a password — it doesn't make a server secure on its own. What protects it is:

  • key-based sign-in, or at least strong, unique passwords;
  • limiting repeated failed sign-ins — for example with a tool such as fail2ban;
  • a firewall that opens only the ports you use;
  • keeping the server's software up to date.

Your credentials stay private

Once saved, a password, passphrase or key file is never shown again — not even to you. Leave the password or passphrase blank to keep the saved one; type a new one to replace it. To change a key, upload a new file; otherwise the existing key keeps working.

Using the e-satisfaction SFTP server

If your organization has an e-satisfaction SFTP server, click Use managed SFTP server. The host, port and username are filled in, and the password is added automatically when you save — nobody needs to know it, and it's never shown in the bridge. This also means a bridge on the server can be copied to another pipeline with Add pipeline and keep working.

The Managed SFTP Server panel then shows the login and the Folder customers upload into, /upload. Organization administrators can click View details to open the account. There's no Test connection here: the account is checked automatically.

Click Change server to go back to what you had before choosing the managed server — or, on a bridge that was already using it, to enter another server's details from scratch.

If your organization doesn't have a server yet, the panel offers Request an SFTP server instead.

The file path and date variables

The file path is the full location of the file on the server (for example, /exports/recipients.csv).

On the e-satisfaction SFTP server, start with /upload/

Files uploaded to the e-satisfaction SFTP server are in the /upload folder, so a bridge's path there starts with /upload/ — for example /upload/recipients.csv. A path such as /recipients.csv looks outside that folder, where no file ever arrives; the File path field warns you and offers to fix it.

To read a different, freshly dated file on each run, you can drop date variables into the path. They're filled in with the date and time of the run, in Athens time:

VariableMeansExample
%Y4-digit year2026
%mMonth, 01–1209
%dDay of the month, 01–3125
%HHour of the day, 00–2314

These four are the only ones a bridge understands. Anything else (such as %y or %M) stays in the file name exactly as typed — the field warns you if you use one.

So a path of /exports/recipients-%Y-%m-%d.csv reads recipients-2026-09-25.csv on 25 September, then recipients-2026-09-26.csv the next day — your export system never has to overwrite the same file.

Help writing the path

As you type, the field shows which file today's run would fetch. Open Date variables and examples under the field for:

  • every variable, with what it means and today's value — click Insert to add it where your cursor is, or copy it;
  • ready-made patterns you can use or copy:
PatternReads asFor
export-%Y-%m-%d.csvYYYY-MM-DDOne file a day
export-%d%m%Y.csvDDMMYYYYDay first, no separators
export_%Y%m%d.csvYYYYMMDDA compact date
export-%Y-%m-%d-%H.csvYYYY-MM-DD-HHOne file an hour
%Y/%m/recipients.csvYYYY/MM/…A folder per year and month

Check that the file is there

Click Check file inside the field to see whether today's file — with the date variables filled in — is actually on the server. You'll see Found, with its size and when it last changed, or Not on the server, or the reason the server couldn't be reached. Nothing is downloaded or imported.

For your own server, the check uses the saved password as long as the server details haven't changed; if you've just pointed the bridge somewhere else, type that server's password first.

Check file isn't available for a bridge still on port 22 — see Port 22 isn't supported.

Mapping your columns

A bridge needs to know which column in your file means what. For each field, you give the column name in your file and the field it maps to:

  • Recipient identifier — required. The email address or phone number to send to.
  • Send time — optional. When the message should be queued for; if omitted, items send as soon as the schedule allows.
  • Language — optional. The recipient's language; if omitted, the item uses Auto detect.
  • Metadata — optional. Any questionnaire or responder metadata fields defined in the workspace, so each recipient carries the right context (store, order, segment and so on).

Pick the workspace first and the bridge offers that workspace's available metadata fields to map to. Only the recipient identifier is required — any column you don't map is simply ignored.

You also set the column separator — comma (the default), semicolon, tab or another character — to match how your file is written.

Scheduling

Two settings control when a bridge runs:

  • Start time — when scheduled runs should begin.
  • Frequency — how often it runs, from every hour up to once a day, with presets in between (every 2, 3, 4, 5, 6 or 12 hours). Daily is the default.

An active toggle turns the schedule on or off. Even when the schedule is off, you can still run the bridge by hand whenever you like.

Testing and running

Test the connection

Before you rely on a bridge on your own server, use Test connection in its Server settings. It tries to connect with your credentials, then reports success or a clear error — so you can fix a wrong host, port or password before any scheduled run depends on it. If it can't reach the server at all, check that your firewall allows our IP addresses. Pair it with Check file to confirm the path, too.

Bridges on the e-satisfaction SFTP server don't need a connection test: the account is checked automatically.

A bridge still on port 22 can't be tested — see Port 22 isn't supported.

Test after every change

Re-run Test connection whenever you change the host or credentials, and Check file whenever you change the path. It's the quickest way to catch a typo before it turns into a missed import.

Run it now

Need recipients loaded immediately? Process now runs the bridge on demand (not for a bridge still on port 22 — see Port 22 isn't supported). You choose which pipeline to load into and see the resolved file path (with today's date filled in) before confirming.

Run history

Every run — scheduled or manual — is logged in the Data Bridges tab of your import history. Each entry shows the pipeline, the result, and whether the run was triggered on schedule, by hand or via the API. If a run fails, no queue items are created and the failure is recorded with details so you can see what went wrong and the next run can pick up cleanly. The import that a successful run opens is listed separately, on the Imports tab, carrying a Bridge type chip.

One bridge, many pipelines

A bridge feeds a single pipeline, but you don't have to rebuild it for each survey. When several pipelines use the same server, file and mapping, they're grouped into one bridge card, and editing it updates them all at once. Use Add pipeline to attach another pipeline to an existing bridge's configuration.