Start with the exchange agreement
First establish what two parties have agreed to exchange. Is it a complete collection of records, a request for a single operation or a sequence spanning several systems? Record when information must be available, which response is required and who owns exceptions.
A file can suit an agreed delivery of data. An API provides an interface through which an application requests information or an action. Batch processing mainly describes handling a collection of work. Orchestration adds coordination between steps. These terms describe different aspects of a process, so they are not mutually exclusive choices.
Product capabilities overlap
MFT products can do more than move files. Kiteworks describes MFT workflows started by schedules, polling, events or manual action. Depending on the available capabilities, a simple file workflow may therefore be managed within the same solution.
Conversely, APIs can handle files themselves. The Kiteworks files API documents file operations, authorisation requirements and transfer statuses. The existence of an API does not determine which management layer you need. Examine the actual agreement, supported capabilities and responsibility for the complete workflow.
A fictional inventory workflow
Imagine a wholesaler receiving an inventory file every evening. An application imports the data following an API request. A batch job then creates an availability report needed the next morning. This fictional example involves three types of work. The following allocation is a possible design, not a description of a completed customer implementation.
On a narrow screen, scroll the table sideways. With a keyboard, focus the table and use the arrow keys.
| Step | Responsibility | Handover agreement |
|---|---|---|
| Receive file | MFT manages the agreed delivery | File reference and transfer status |
| Request import | API exposes the application function | Request reference and response |
| Create report | Batch job processes the required data | Result and completion status |
| Coordinate sequence | Chosen orchestration layer coordinates steps | Start conditions and responsible contact |
Define ownership at each handover
The file, import request and report belong to the same business delivery. Choose a recognisable reference that connects those steps. Also agree which response allows the next step to proceed. This makes responsibilities explicit without requiring every operator to understand the internal details of every other system.
An orchestration product can include different kinds of work within one schedule. Control-M Web Services REST describes a single REST call per job, alongside dependencies, scheduling and integration with other jobs. The plugin has component and minimum-version requirements. Its documentation does not establish that every existing API contract will fit without adjustment.
Assign one owner to each decision. For example, let one layer decide when a new import is started. If a local workflow and a central scheduler can independently restart the same step, understanding the intended behaviour becomes harder. The receiving application also needs an agreement for handling repeated requests.
An API acknowledgement that a request was accepted does not prove that the import is complete. With asynchronous processing, completion follows later. Start the next task only on the agreed processing confirmation; see also what to check when a file was sent but not processed.
Choose the smallest setup that covers the process
An additional orchestration layer is not automatically necessary. For a few straightforward steps, an existing workflow facility may be sufficient. A central solution becomes more relevant when several applications, dependencies, schedules or teams need to coordinate the same process. Base that decision on the workflow rather than the number of features a product offers.
Consider operating effort, skills and licences as well. BMC describes MFT Enterprise as an add-on for external file exchange. Check which modules are actually needed and available. A product name alone is insufficient to establish costs, technical capabilities or included entitlements.
What to do and what to avoid
Do: map the workflow and record the input, response, owner and start condition at each handover. Keep existing facilities where they adequately support the agreed process.
Avoid: rebuilding the entire schedule and decision logic in several tools. Do not choose an API simply because it sounds more modern, or MFT merely because a file appears somewhere in the process.
Current context: management APIs and previews have different status
Checked on 29 October 2026. The BMC Automation API release notes list workspace export and check-in under version 9.0.27.000 from September 2026. MCP Server is explicitly listed in the August release as a preview for non-production environments. Available management functions do not imply production-ready autonomous process control; check the status of each capability.
Short questions about responsibilities
Does an API replace MFT? An interface choice can change the solution required, but APIs and MFT can also work together. Start with the exchange agreement.
Can MFT run workflows itself? Some products provide workflow capabilities. Assess whether they cover the relevant dependencies and systems.
Should every batch job be scheduled centrally? No. Centralisation is useful when shared coordination provides enough value to justify the additional management effort.
Explore the broader context of Managed File Transfer and automation to assess responsibilities from the business process outward.
Make responsibilities visible
Map one file workflow and identify who starts, manages and completes each step. Discuss where scheduling or decision logic is duplicated.
Discuss your question