Trace file transfer history and user activity
Knowing that a transfer finished does not answer every question that comes up in operations. You need to see which job ran and when, which device the files left and where they went, and where a failure happened. Trace the run history around INNORIX Studio Runs, read it together with the user, job and state information the product provides, and assemble the evidence that operational review and audit need.
Wie es aufgebaut ist
- Identify the transfer you want to trace.
Gather the clues you already have — the job name, the run time, the source and target devices, or the Run identifier. If all you have is a user name, first check whether that field is searchable.
- Open the Runs history in Studio.
Review the run outcomes — finished, failed, interrupted — and find the job in the run records for the period you need. Use only the period, state and device filters the product actually offers.
- Read the transfer path and the result in the Run detail.
Review the Flow, the source and target devices, the start and end times, the transfer state and any error information. Per-file detail and integrity results are there to read only where they are provided.
- Tie the run back to the user activity.
Confirm the audit items you need — who ran it, whether it was scheduled, whether an administrator changed something — against the actual records. Keep anything Runs cannot confirm separate, as evidence drawn from the authentication system or operational logs.
- Write the findings up as an audit and operations record.
Record the Run identifier, when you checked, the target devices, the result, whether it failed and was recovered, and the screens that support it. If an export feature is not provided, keep the record in a supported form of review and note-taking, and check the retention period and the access permissions.
Wo es eingesetzt wird
- Evidence that a scheduled batch finished
Check the run record to confirm that the overnight settlement file transfer ran at the time planned and completed all the way to the target server.
- Settling a question between departments
When a receiving department says a file never arrived, use the source and target devices and the run result for that transfer as evidence. Whether the target application actually processed it is verified separately.
- Investigating a failed transfer
Trace when it failed and which device or stage produced the error, and follow it through to the final result after a retry or a resume.
- Reviewing transfer history with a partner
Check when an outside partner ran a permitted Flow and what the result was. Use partner account identifiers only as far as they appear in the actual records.
- Operational handover and incident reporting
Write up the significant Runs for a given day along with the failures and recoveries, so the next person does not have to re-investigate the same transfers.
- Security review and internal audit
Look for jobs that ran outside the nominated times or transfer paths that were not expected. Attributing actions to a real user means cross-checking the authentication and permission records.
- Comparing results before and after a policy change
Compare the run results before and after a Flow configuration change to see whether operations were affected. Who changed the setting and what they changed can be tied in only where a separate audit record is supported.
Anwendungsleitfäden
Häufig gestellte Fragen
Can an enterprise file transfer solution show who sent which file and when?
Tracing the job, the time, the source and target and the result from the run history is the baseline. Whether user identity and individual filenames are recorded has to be checked against your INNORIX deployment version and its logging configuration. Run history alone does not tell you the contents of a file or everything a user did.
Can past records be looked up again after a transfer has finished?
You can operate on the basis of reviewing the retained run history through Studio Runs. The period you can query, how long records are kept, and the deletion and archive policy have to be checked on your own environment.
Can we trace which server a file moved from and which server it moved to?
Reviewing the source and target devices and the run information tied to a transfer Run and its Flow helps you trace the path between devices. For a Flow with several stages, check how far per-stage records are provided — and a subsequent move made outside the devices is not traced automatically.
Can a transfer a user ran in Portal be distinguished from a scheduled one?
Operationally, manual and scheduled runs do need to be distinguishable. Check whether the run type and a user identifier are actually provided in Runs or the audit log, and do not assume fields that the screen does not display.
Does the history also show a transfer that failed and was then recovered?
You can judge whether it recovered from the failure state and the result of the run that followed. A resume within the same Run and a fresh run as a separate Run may be linked differently in the records, so work from the actual Run identifier and state.
Can transfer records be downloaded as a CSV or a PDF audit report?
Whether report export is supported has to be checked on the product version. Where it is not, you can write the report by combining the information Runs shows with your own operational records — an unimplemented download button should not be demonstrated.
Is transfer history alone enough to meet security audit requirements?
Transfer history is important audit evidence, but it has to be reviewed together with authentication records, permission change history, system clock synchronisation, tamper protection and the retention policy. It does not guarantee automatic compliance with any particular regulation or certification.
How should personal data and access permissions be handled when tracing user activity?
Collect only the information the audit purpose needs, restrict who can query it, and follow your retention and deletion policy and the relevant regulations. Check too whether per-user activity lookup is actually supported and who is allowed to read the audit records.