One Flow for every transfer.
Complex work, done end to end.

It waits or retries according to the policy you set. Once the server reconnects, the transfer resumes from where it stopped, and the next stage proceeds when the completion condition is met. Transfers to other targets continue unaffected.

This is handled by the duplicate-run policy. If a new run is requested while the previous one is still running, it can be queued and run in sequence or blocked altogether, and you can define a transfer time window so runs do not overlap.

By the Assurance Contract. You define success conditions in advance, such as required stage completion, required targets, file integrity and the allowed completion time, and the run result is verified against them. Even if every file arrived, the run is judged a failure if it missed the deadline or a required target, and you can see which condition was not met and why.

It depends on how required targets are defined in the Contract. A missing required target is judged a failure, while a non-required target that was not reached does not affect overall success. The run policy also decides whether the next stage waits for all targets or proceeds with the ones already completed.

Yes. Open a Flow run in Runs and select a stage and device to see the per-file transfer history. Completed and interrupted files are distinguished and searchable by file name, and the number of errors, recovery attempts and final status of each run are recorded as well.

Yes. Scheduled runs start the Flow hourly, daily, weekly or monthly at a set time, and event runs start it when a new file appears in a specified location. Both can be set together.

Yes. Each stage specifies its own files and conditions, so a large-file leg and a leg with many small files can sit in the same Flow. See the shared Large and massive file transfer page for details on the transfer technology.

Yes. A stage's source and destination can be a server, a field device or cloud storage. See the shared Long-distance, high-speed transfer page for transfer performance over long-distance network legs.

Transfer legs are encrypted, and per-stage execution, file processing, errors and recovery attempts are kept as run history. External security tools can be integrated to scan files before and after transfer. See the shared Security and audit page for details.

With the API and SDK, your existing systems can create and run Flows and query per-stage status and results. Run status and results can be posted to external services such as Slack and Datadog, and external AI can request Flow runs through INNORIX MCP.

No. Flow design, run conditions, failure policies and the Assurance Contract are configured in INNORIX Studio without code. The API and SDK are only needed when you want to run Flows or consume their results from inside an existing application.

Yes. Start for free, connect servers and devices, build and verify collection, transfer and distribution Flows yourself, then switch to the license your enterprise operations need. See the Pricing and licensing page for terms.

Breaking the work into stages. Decide which files go from where to where, what condition starts each stage, how far to reprocess on failure, and what must be satisfied for the job to count as done (the Contract); the Flow design follows from there. For environments with many sites, private networks and hundreds of devices, review it together with an expert consultation.