"Inbox/Outbox" vs. Folders When Designing File Transfer Workflows

In the automated file transfer world there are two general user experiences.

Workflow #1: Inbox/Outbox - When an end user (or application) signs on, it sees either one or two folders: an "inbox" where it can drop files and an "outbox" where he/she/it can pick them up.  Frequently when items are placed into the inbox they disappear into an internal system almost immediately.  Frequently when items are downloaded from the outbox they also disappear immediately.

A common variation on this is the combined inbox/outbox where any items visible to the end user are "outbox" items and end users simply upload new items, which do disappear immediately, to the same folder.

Workflow#2: Folders -  When an end user (or application) signs on, it is locked into it's own home folder, but it also sees a number of folders into which it can upload files and other folders from which it can download files.

Workflow #1 is more typical of legacy applications, particularly products that predate 2000 or have mainframe roots.   Workflow #2 is more typical of applications that grew up on Windows, *nix.   However, both designs are still in wide use today.

As time goes on and companies wish to reuse their existing customer and partner connections for new projects, products oriented around workflow #2 are slowly winning out.  This is happening for two reasons.

First, most products that can support workflow #2 can ALSO support workflow #1.  (MOVEit products are among those in that happy category.)   In fact, if you look closely enough, you see that workflow #1 is just a restricted version of workflow #2.

As needs become more complex, it is increasingly common that new file transfer deployments will have some workflow #2 users, even if the main project intent is to support and migrate a large number of workflow #1 users.  Thus, unless the only intent of a project is to replace an aging deployment workflow #1, project managers with an eye toward the future tend to favor the flexibility of workflow #2.

Second, the rigid inbox/outbox model of workflow #1 drives up expense when multiple lines of business ("LOB") or departments are involved in either side of the exchange.  For example, to facilitate communications between the "CheckPrint" and "OnlineBank" LOB at ItemProcessorA and the "Personal" and "Commercial" LOB at BankB, workflow #1 would tell ItemProcessorA to provision 4 users (e.g., "BankB_CP_Personal", "BankB_CP_Commercial", "BankB_OB_Personal", "BankB_OB_Commerical") and 8 mailboxes (inbox/outbox for each user).  Workflow #2 could economize in only a single user (e.g., "BankB") and 4 main folders, one for each LOB-to-LOB combination.

While the difference between 1 and 4 users may seem insignificant on paper, when you consider that some organizations budget $1,000.00 to provision and maintain EACH individual username, the savings (75% in this example) can be striking when thousands of users or several lines of business are in play.