Let business users run a server-to-server transfer themselves
Sending material an analysis server needs, or moving result files off a working server into storage, no longer means a ticket to IT every time. An engineer sets up the permitted servers, paths and run permissions in INNORIX Studio; the business user then picks an allowed job in Portal, runs it, and watches the progress and the result. No server accounts and no transfer scripts have to be handed out.
- Prepare the server-to-server Flow and Portal permissions in Studio
- Business user picks the job in Portal
- Review the permitted source files and target server
- Run the transfer
- Check progress and the finished result
A business user runs a file transfer between two servers that was approved in advance. Unlike the 1:N distribution in guide 25 or the N:1 collection from many devices in guide 26, this page shows a 1:1 job from one source server to one target server. Portal is, by default, the screen for running and monitoring transfers between devices — not a screen for uploading files from a user PC or downloading server files through a browser. Web upload and download belong to INNORIX EX.
How it is built
- The engineer connects the two servers.
In Studio Devices, register the source working server and the target analysis or archive server, and confirm read and write permissions on the folders involved.
- Build the server-to-server Flow.
In Flows, set the source device and path and the target device and path. Decide the range of files the business user can pick, how filename conflicts are handled and the run conditions, within the settings the product actually supports.
- Publish the job in Portal and grant permissions.
Give the job a name and description the business user will see, and grant run and status permissions on that Flow. Add an approval step or a run time window if you need one.
- The business user starts the transfer.
In Portal, open the permitted server-to-server job, check the source files and destination shown, then run the transfer. If the same job is already running, check the existing run instead of starting a duplicate.
- Check the result in Portal.
Review the progress and whether the job finished, is waiting or failed. If there is an error, the engineer investigates the detail in Studio Runs and reruns whatever needs rerunning.
Where it is used
- Finance data to the analysis server
A finance user sends the closing CSV written by the accounting server to the analysis server and confirms it arrived. Running the analysis itself is a separate job.
- Quality reports to the review server
A quality user sends inspection result files held on the production server to the review server. The job is scoped so that only approved folders can be picked.
- Video and design output between working servers
A content user moves large files from the editing server to the rendering server. The business user runs the transfer and confirms it finished, without handling server credentials.
- Project material into archive storage
A project manager moves finished deliverables from the operations server to the archive server. Whether the originals are deleted is governed by a separate policy — a transfer is not a delete.
- Research output to downstream processing
A researcher sends data files produced on the measurement server to the analysis server. The engineer defines in advance which file types and target paths are allowed.
- Support logs for internal analysis
A support agent passes diagnostic logs from a nominated service server to the internal analysis server. Browsing the whole server or reaching arbitrary paths is not allowed.
- Material shared between business units
A sales operator sends approved reports from the department server to another department working server. On-demand run permission for business users can sit alongside the scheduled jobs.
Usage guides
Frequently asked questions
Is there software that lets non-developers run server-to-server file transfers themselves?
INNORIX is a file transfer platform you can set up so that engineers build the server-to-server Flows in Studio and business users run the permitted jobs from Portal. Business users can follow the state of a transfer without touching server commands or transfer scripts.
Can business users send files without being given server login accounts?
Yes. The engineer configures the server connections and transfer paths in Studio, and the Portal user is granted nothing more than permission to run the nominated jobs. How far account and role-based access control goes should be verified on the version you deploy.
Can a Portal user pick any source file or any target server they like?
What a user can select and change in Portal has to follow the jobs and permission policy the engineer set up in advance. It is not designed as a general-purpose admin screen for browsing and transferring across every server and folder.
Can Portal upload files from a personal PC to a server, or download server files?
Portal itself is a product for running and monitoring predefined transfers between devices. Attaching a file from a personal PC in the browser to upload it, or downloading a server file through the browser, is not part of Portal. Web upload and download are a matter for INNORIX EX, or for customisation against a specific requirement.
Can a transfer require administrator approval before a business user runs it?
An approval condition or a run time window can be considered, depending on your own policy. How far approval screens and approver roles are implemented has to be checked in the product — do not assume an approval step that is not built is provided as standard.
If a transfer takes a long time or is interrupted, how does the business user find out?
Portal can be set up so the user sees the progress of a running transfer and whether it finished or failed. Detailed causes and recovery are handled by an operator in Studio Runs. How recovery works can vary with the state of the network and the devices.
What happens if several business users run the same transfer job at once?
When the same job is already running, the recommended behaviour is to point the user at the monitoring view for the current run rather than unconditionally creating another one. Duplicate-run limits, rerun permissions and conflict policy have to be configured and verified against the product implementation and your own operating rules.
Is there a record of the transfers business users ran?
Studio Runs shows the run state and result of each transfer job. To trace who ran a job in Portal, check on your own deployment how user identity is tied to the run record and how audit log retention is configured.