What Is an Import Run Log?

An import run log is the file written once per import run that records every row the run processed, the outcome each row received, and the exact reason behind every failure. It is the difference between knowing that an import "mostly worked" and knowing that row 47 of this morning's price file had a blank product id. In EDGEBIC by User Solutions every run produces its own log, opened straight from the result dialog, and kept until you choose to delete it, so a data load is never a black box.

How it works

An import run ends with a result dialog rather than a silent close. That dialog summarizes the run on one line, counting rows created, updated, reused and failed along with the elapsed time, and beneath it a grid gives one entry per file row.

The log holds all of that and one thing more: the rows the dialog hides. A source file can contain rows that are not user data, and the dialog filters those out so the grid stays readable while the counts still cover everything the run touched. When a count and the visible grid disagree, the log is where the discrepancy is explained.

The file itself is written into the application's local log folder, one file per run, named after the mask and the run timestamp. Nothing prunes it automatically, which makes the folder a chronological history of every load anyone has performed. That is genuinely useful months later, when the question is not "did it work" but "when did this product's cost last change and what changed it."

Reading the log well means knowing what the messages are usually telling you. A row whose key cell is blank fails with a required-field message and is fixed in the spreadsheet. A row whose value does not resolve, such as an actuals row naming a job and work center that do not correspond to a scheduled operation, fails for a different reason and is fixed by checking the spelling against the schedule. And a run that aborts before any row is processed is not a data problem at all: it means a field the mask marks as required was never mapped, which is fixed by editing the mask. The row-level side of that distinction is covered in what is row-error tolerance in a data import, and the outcome vocabulary itself in what is an import row status.

A concrete example

A planner runs the saved weekly product mask against this week's price file and the result dialog reads: created 3, updated 0, reused 1, failed 1, two seconds.

The counts alone already say a lot. Three products in the file did not exist and were created. One matched an existing product and was left alone, because the mask's update option is off by default and matching without updating is the safe mode. One row failed.

The grid names the failed row and shows its message. The planner opens the log from the dialog's button, confirms the row number, and sees that the key cell was empty. The fix is one cell in the source spreadsheet and a re-run, which is harmless: the three created products come back as Reused, the matched one stays Reused, and the corrected row lands. The log for that second run sits beside the first, so both attempts are on the record.

Contrast that with a routing import gone wrong. The counts read created 5 and everything looks healthy, but the routing shows fewer steps than expected in the designer. The log answers why: a product's steps were split across two files, and because a routing import replaces that product's entire routing per run, the second run's replacement removed the first run's steps. No row ever reported Failed, because nothing was invalid. Only the log's chronology, showing two runs against the same product, makes the sequence visible.

How EDGEBIC uses it

The result dialog appears after every run and carries the button that opens the log. Because the log is written per run rather than appended to a single rolling file, the folder reads as a history rather than as a wall of text.

Three habits make the log pay for itself:

• Read it after any run with failures. The dialog gives counts; the log gives row numbers and reasons. Skipping straight to the source file and guessing is how one bad column becomes a weekly ritual.
• Keep the logs from the runs that changed prices, rates or routings. Those are the loads people ask about later.
• Tidy the folder periodically. Nothing removes old files for you, and a year of daily runs is a lot of files.

Keep one boundary in mind while reading a log. An import writes data and never recalculates the plan. A run that lands forty new orders leaves forty jobs waiting to be scheduled, and the log records the data landing, not any effect on a timeline. If a promise date is wrong, the log tells you whether the underlying data arrived correctly, and the scheduling run is a separate question.

The takeaway

An import run log turns a bulk data load into something you can audit and troubleshoot precisely: one file per run, one line per row, an explicit reason on every failure, and no automatic deletion. Read it whenever a run reports failures, and keep the ones that touched numbers people care about. To see the result dialog and the log in a working system, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring import terms, read what is an import entity type and what is an upsert in data import.