---
url: /statelake/administering-statelake/designer/transports/inbound-transports.md
---

# Inbound Transports

**Inbound Transports** provide a connection to a location that you can retrieve files from.

**Transports** are typically used in *business-to-business* transactions where data files have to be transferred from one business to the other, although other **Transport** scenarios are supported.

You configure the **Inbound Transport** with the appropriate details for connecting to the source location and retrieving any files that match your requirements. The **Inbound Transport** will always activate with a particular **File Connection**, and it is the properties of this **File Connection** that determine the filter for matching files.

**Inbound Transports** are assigned to **Actions**. You can then provide the schedule upon which the **Inbound Transport** checks the remote server or service for new files. Commonly, an **Action** using an **Inbound Transport** will be set to **Monitor for incoming files**, and the **Inbound Transport** will be scheduled to run every few minutes or hours. The **File Connection** that has been set on the **Action** for monitoring is the one used to filter the matching files on the **Inbound Transports** remote location.

Many of the **Transport** types are based around industry-standard protocols.

These protocols vary in the security and reliability that they offer - some allow encryption of data, while some provide more rigorous proof-of-delivery features.

Basic file transfers can be achieved by sending data files as attachments to email messages. Files can be retrieved from an email account using a **POP** or **IMAP Transport**.

Access to the messages is controlled by the server and the protocols, and the data can be encrypted during retrieval. However, there is almost no control over what messages are received into the email account (e.g. spam), and inwards messages are not encrypted. One of the disadvantages of using the email protocols is that messages may include such things as company logos, which appear to be *attachments* but are not the data file attachments that we are wanting to work with.

If inwards controls such as spam filters are in place, then there is a risk that valid messages will be filtered out and will not be available to **Statelake**.

Inbound messages to an email account can be shared across multiple **Trading Partners** and this may cause a bottleneck when trying to identify which message is which. In many such cases, a **Statelake File Router** action step within the **Action** can be configured to help manage the situation.

**File Transfer Protocol**, or FTP, offers more control over the transfer of files.

If an **FTP** account has been set up with a password, and if encryption is used, then file transfers are protected from initial posting through to retrieval onto your **Statelake** server. The server would not be open to unsolicited files. An **FTP** server can have multiple accounts, and files can be placed into sub-directories if required.

If the **FTP** server is hosted away from your **Statelake** server, then an **FTP Transport** can be used to retrieve files. If you are hosting the **FTP** server, and files are being uploaded to your server, and if **Statelake** has access to the sub-directories on your **FTP** server, then a **LAN Transport** can be used to transfer the files across to Statelake, because the file locations are now essentially *local* to Statelake.

The other **Statelake Transport** types are not used as often, but they allow your configuration to fetch files from a variety of sources if the need arises.