Run History

What a run is

Every time the SMART Migration server claims a job, it opens a run: one row in Run History, linked to its job. A job that runs again — a migration repeated before go-live, a recurring copy, a job switched from Discovery to Migration — gets a new row each time, and all of a job's runs are listed together.

Each row records:

the job's title, group and tags as they were when it ran,
its mode, status and result — Ok, Warning or Error,
its start, finish and duration,
its progress and its latest message while it runs, and its summary when it ends,
the files, versions and volume it handled, and the number of file issues,
its source and destination, and a link to its report and its folder in Nextcloud Files.

The configuration is kept with the run

When a run starts, the job's configuration is copied into it. The job can be edited afterwards; the run's record cannot, so it stays the account of what that run actually did — which source, which filters, which destination.

A snapshot of the job, with room for your own notes

A run's properties are a snapshot of the job as it was configured when the run started: its title, group and tags, its mode, its source and file filters, its destination and every other setting. The run's details show them under Configuration details. Change the job afterwards — a wider filter, another destination — and the runs already made keep what they ran with; only the next run takes the new settings.

What the run did can never be edited. What you may change is how the Run History is organised around it, and what the run is called:

You can	How	What it is for
Write My note	On the run's pinned summary card, or the Dashboard's run card	What was found, agreed or still to check about that one run
Rename it, or write its description	`Title` and `Description` in the run's details, then Save	Saying what the run was for, apart from its job — a trial, a re-run after a fix
Move it to another group	`Job Group` in the run's details, or Change selected runs … in the row menu or in Actions for two or more ticked runs	Filing a run under the wave it belongs to, apart from its job
Add and take off tags	The Tags cell, or Change selected runs … in the row menu or in Actions for two or more ticked runs	Grouping runs across jobs — a wave, a sign-off, a re-run to compare
Pin it	The Pin column, the run's details, or Change selected runs … in the row menu or in Actions for two or more ticked runs	Keeping the runs in hand at the top of the table
Archive it	The Arch. column, or Change selected runs … in the row menu or in Actions for two or more ticked runs	Putting signed-off runs away out of everyday work

None of these touches the record: the source, settings, result, counts and report stay exactly as the run left them, and the job keeps its own tags and note.

A job and its runs: the plan and the record

A job and its Run History rows are two different things. The job is the plan — what to do, where from and where to. A run is the record of one time SMART Migration carried that plan out. One job has many runs over its life; each run belongs to exactly one job.

	The job	Its Run History rows
What it is	The definition: mode, source, file selection, destination, metadata, schedule and notifications	One session of SMART Migration working that definition: what it found or moved, and how it ended
How many	One per source	One more each time the job is claimed
Changes	You edit it, change its status and run it again	Written by SMART Migration while it runs; then fixed, with a copy of the job's settings as they were
Lives on	The Jobs tab	The Run History tab, the run's details and its folder in Nextcloud Files
Feeds	What runs next	The Dashboard, File Issues and the Power BI report

Work with the job to plan and steer

Define the source and destination, organise the jobs in groups and tags, schedule them and set them to Ready. Switch a job from Discovery to Migration, or run it again before go-live: the same job, a new run each time.

Work with the runs to follow and prove

Watch progress while a run works, read its result, log and report, and the files it could not migrate on File Issues. Years later, the runs still answer where a file came from and how many files, versions and how much volume each wave moved.

Run a job again, as often as you need

A job can run any number of times, and each run can turn out differently. Say a Discovery job's From Date was set too narrow and its report shows too few files: widen the filter on the job and set it to Ready again. The first run stays as it was, with its own Run History row and report; the new run gets a row and a report of its own, with the settings it ran with. Compare the two side by side, and keep the run that answers the question. A Discovery job is also worth running again with other filters — another size or date range — or with the same ones later on, to see how the source changes as time goes by.

A Migration job is run again for another reason: to bring over what is new or has changed since its last run. It is incremental by default — the rule Add New Overwrite Existing By Newer — and the rule can be fine-tuned, for example to add new files only.

Arriving from a job — its summary card, its dialog or the runs mark beside its Result — shows that job's runs alone: the tab's other filters are cleared, the rows are sorted by Start, newest first, with any columns sorted before as the next levels, and the newest run is the current row, marked and on screen.

The two lead to each other. On the Jobs tab, the runs mark beside a job's Result shows what its runs did, and its pinned card opens them on the Run History tab; on a run, Goto Job definition, at the end of the line of the run details' tabs, opens the job it was made from. Archiving or deleting jobs asks whether their runs go with them, and a deleted job's runs can stay: the record can outlive the plan.

Read the Run History table

The columns are: Title, Source, Destination, Mode, Status, Start, Finish, Duration, Files, Volume, Versions, Ver.vol. (version volume), Result, Group, Tags and Reports. The four figures are the new and the modified files the run counted and moved — New + Modified, the files unchanged since the BI data last held them left out — as in its details, and sort as numbers — an empty or greyed-out cell as the lowest value; a Job Import run leaves them empty, and a file share, which keeps no version history, has its two version cells greyed out. The Reports column has no title, so it is only as wide as its folder button — rest the pointer on its header for its name. Source and Destination carry the same marks as on the Jobs tab: the source's kind, and a team folder or a user for a migration's destination. Every column always shows. A narrow window first narrows the text columns and cuts the group names short; when it is still too narrow, the table scrolls sideways: the row menu, the tick boxes and Title, with the text filter under it, stay in place at the start, and the Pin column at the end, so you always know which run a row is. While the table scrolls sideways, the lines after Title and before Pin turn blue: the columns between them are the ones that scroll, and the scroll bar under the table spans just those columns. A run's progress shows when the pointer rests on its row, and its message and progress are in its details.

Rest the pointer on a run's status for a card that says in plain words what it means and what to do — for Canceling, that SMART Migration stops the run as soon as it can, midway, and that the run is then best deleted to keep the BI data consistent. Click the status to pin the card: Details, Session log, Goto Job, and Cancel job while the run is under way. See Job status
Rest the pointer on a run's result for a card that explains it: what Ok, Warning or Error means, what SMART Migration reported with it — its message, its summary, the errors and warnings in its session log and its file issues, when it started and finished and how long it took — and what to do next. Click the result to pin the card: Details opens the run's details, Session log opens them on the Log tab, File issues shows the files on the File Issues tab, and Goto Job the job the run was made from.
Result also shows, beside the result, the issues mark and how many file issues the run recorded; click it to see those files on the File Issues tab. A run without issues shows nothing there. The filter under Result picks a result, or — last in its list — With file issues: every run that recorded file issues, whatever its result — a cancelled run included — sorted with the most issues first. The Result header then shows that sort; click it to sort by result again. Sorting on Result also puts the runs with the most file issues first within each result.
Reports shows a folder mark when the run has a report or other files in its own folder. Rest the pointer on it for a card listing what the folder holds — the report SMART Migration uploaded, the run's session log exported as a spreadsheet, a file list or the CSV file an import read — each with what it is, its size and when it changed. Under the report, its figures: what a Discovery found or a migration moved — files, volume, versions and, for a migration, file issues. A click on a file's line opens it in Nextcloud Files, and the mark pins the card, with Open folder in Nextcloud Files for the folder — each in a new tab. A run with nothing there yet shows no mark. The run's folder sits in its job's folder, inside the Team Folder SMART Migration Reports that holds every report — see Reports and run folders in Nextcloud Files
A run's title is its job's title with the run's number on the end — Finance Docs (Run: 3) is the job's third run in that mode. Each mode counts on its own: a job's Discovery, Migration, Test Migration and Import runs each start at 1. The number is given as the run starts and never changes; copying a job starts the copy at 1 again.
Rest the pointer on a run's title, or on one of its figures — Files, Volume, Versions or Ver.vol. — for its summary card, and click to pin it: its mode, status and result, its start, finish and duration, then under Outcome the run's message, on its result's colour, and its figures in a small table — Files, Volume, Versions and Version volume (the two version rows left out for a file share, which keeps no version history), each apart for the New and the Modified files, with their Total; a Discovery run adds the Unchanged files, the ones the BI data already holds as they are, and its total counts them too. The parts stand together on a yellow band under the heading Compared with the BI data (rest the pointer on it for what that means), and the lines under the table say what each part is; Total stands apart from the band, as every file the run reported: Files New 15 on a Discovery run means it found 15 files the BI data did not hold yet — then Issues Count, left out on a Discovery run, which records no file issues; each figure a dash for none or while not reported yet — and its source and destination. Its foot says who created the run, with its Run History ID and Job ID at the right. An Import run has none of these figures, as it makes jobs rather than moving files. A volume too small for a whole megabyte reads in KB, or as < 1 KB.
Double-click a row, or choose Details in its menu, to read the run's details and its log. See Run details and the session log
Right-click a Source or Destination cell for Copy URL — Copy UNC path for a file share — and Open SharePoint location, which opens the library in SharePoint in a new browser tab, at the head of the row menu.
Goto Job, in the row menu and on the run's card, takes you to the row of the job the run was made from in the Jobs table, without opening it. When the job sits far down a long list, the Jobs table is filtered on its title to bring it there; clear the filter to see every job again.
Tags and Archived, marked with a grey pencil, can be changed right in the table. For Tags, click the cell, pick or type a tag and press Enter. Only the run's own record changes — its job keeps its tags, and a later run takes the job's tags as they are then.
Actions, above the tick boxes once a row is ticked, has Change selected runs … — one dialog for the group, tags, pin and archive of the ticked runs, with a switch per property: whatever stays off is left as it is — and Delete …. The row menu and the pinned summary card have Change selected runs … too, for the ticked runs the row is part of. It is greyed out until two or more runs are ticked: one run is changed in its details.

The rows can be shown as a Tree — under their group, site, library and folder — or as one List, and filtered by text, source type, destination type, mode, status, result, group, tags and duplicates — the source type under Source, the destination type under Destination. A run that is still under way can be cancelled from its row menu. The Duplicates filter works here as on the Jobs and File Issues tabs: see Find and clear up duplicates

Show only the latest run of each job

A small green star at the end of a run's title marks its job's latest run — the newest, whatever the filters show. The run's card carries the same star beside its title, and its Latest run line says whether this is the job's latest run; the switch carries the star too. So with the switch off, or beside an older run you have pinned, you can see at a glance which run is the current one.

The Latest run per job switch beside Duplicates in the tab bar shows only the latest run of each job — its newest, among the runs the other filters let through. With Mode set to Discovery, it lists each job's latest Discovery run; with Status set to Finished, each job's latest finished run. A run you have pinned always shows, in the Pinned band above the table, even when a newer run of its job is there — the other filters still apply to it. The count beside it says how many runs that is. The Dashboard's Runs in Run History box has the same switch, and switches for the modes and the results that set the Mode and Result filters — each takes several at once: turned on there, they are on here too, and a click on that box opens this tab with every other filter cleared. The switch is on when the app opens, and remembered while the browser tab is open; opening a job's runs from the Jobs tab turns it off, so every run of that job shows.

Opened for one job — from the Jobs tab, the job dialog's Run History or the Dashboard — the tab shows only that job's runs, and a frame above the table says Showing runs of job …. Rest the pointer on the job's name there to see its card; click it to pin the card. It stays when you go to another tab and come back; Show all runs brings every job's runs back.

Status and result of a run

Status	Meaning
Running	The run is under way. Its Progress is updated as SMART Migration reports it.
Canceling	A cancel was asked for and the server is stopping the run.
Finished	The run has ended. Its Result says how it went.
Canceled	The run was stopped before it ended. Its finish time is when SMART Migration stopped: the time of the last message in its session log.
Deleted	The row was deleted: it is gone from the table, and waits for SMART Migration to purge its data from the reporting database.

A run that finished with Warning did its work but met something that needs a look, such as files that could not be handled as expected; with Error, something stopped it from doing its work. The run's details say what: its message and its log.

Pin runs to the top

A pinned run moves to the top of the table: it is listed apart, under a Pinned band above the tree or the list, and no longer in its group below — whatever the sort, with a line in orange down its start edge. They stay in view under the column titles while the rest scrolls under them, as long as they take at most three quarters of the table's height; more than that, and they scroll with the rest. The Pin column at the far right shows a solid pin on a pinned row and an outline on the rest; click it to pin or unpin that row alone. An unpinned row leaves the band and the table stays where it is; the toast that says so takes you to the row. To pin or unpin every ticked row, use Change selected runs … in the Actions menu.

The run's details have Pin and Unpin too, beside the Job heading on the Details tab; Change selected runs … in the row menu, the pinned summary card and the Actions menu pins and unpins as well.
Pinning changes nothing else: the run keeps its place in the tree, its status and everything SMART Migration reads.
Pins are your own: each administrator pins for themselves, and no one else sees your pins. A job's retention schedule keeps a run any administrator has pinned.

My note on a run

My note is a few lines kept with one run: something important about that one run — what was found, what was agreed, who is looking into it. Write it on the pinned summary card: click the title, write in My note about this Run beside the Run section; it is saved when the card closes. The Dashboard's run cards offer the same note, and the run's details dialog has it under Description, saved by its Save. It is your own: other administrators do not see it, and each can write their own. SMART Migration never reads it. A run's note is its own: its job's note is not copied into it. The text filter under the Title column reads notes too, and a run with a note shows a small orange triangle in the top-right corner of its title; a run with a description shows a blue one in the bottom-right corner, as on the Jobs tab. A small yellow triangle in the top-left corner instead marks a run whose title, description, tags or group was changed here and has still to reach the BI data — see Run details and the session log.

For how to use notes with groups, tags and the archive, see Organise the jobs of a project

Archive Run History rows

Archiving puts runs away out of everyday work, where deleting would remove them. The Archived box at the far right of each row archives the run, or takes it out of the archive; with several rows ticked, the click applies to all of them, as does Change selected runs … in the Actions menu, after a confirmation that Do not show this again skips for you.

An archived run is left out of the Run History tab — the table, its counts and its filters. The count in the tab bar says how many are left out — 54,970/54,970 · 4 archived. The Archived column is titled Arch.; the box under its title filters by it, in three states: empty while the archived runs are hidden (the everyday view), a bar across it while every run shows, ticked while only the archived ones show — click it to move on to the next.
Nothing else changes: the run keeps its record, and its data stays in the Business Intelligence report.
Archiving a job on the Jobs tab can archive its runs with it.

Jobs and runs are archived independently

A job and its runs each have their own Archived flag, and one never forces the other. Archive old runs and the job stays in everyday work; archive a job and choose whether its runs go with it; take either out of the archive without the other.

The point is less clutter. A job that runs every day leaves a run a day — hundreds over a migration. Archive the runs that are checked and done, and Run History shows the ones still worth reading, while the job keeps running and the archived runs stay one click away under Arch.

Archive or delete: what happens to the BI report

Archiving and deleting look alike in the table — the run leaves it — but they do opposite things to the Business Intelligence data:

	Archive	Delete
On the Run History tab	Left out of everyday work; the Arch. filter brings it back	Gone for good, once SMART Migration has purged it
The run's data in the BI report	Stays: the report still counts the run	Removed: SMART Migration purges it from the reporting database
When	At once	Later, on the SMART Migration server's next check — not at the click
Undo	Take out of archive	None

The removal from the BI data happens on the SMART Migration server, separately from the app and some time after the click. Until it is done, the mark on the Dashboard's Power BI heading is red and says how many deleted runs are still to be purged — rest the pointer on it for the details; once it is back to a green Up to date, the reporting data is up to date and the Power BI report can be refreshed.

Delete Run History rows

Deleting a run by hand is meant for test runs and mistakes: the rows are the migration's record. For housekeeping, give the job a retention schedule (below). Delete the ticked rows with Delete … in the Actions menu, or every run under a group, site or folder with Delete all in group … (Delete all in this location … on a site or folder) on that row's ⋯ menu in the Tree view; runs still Running or Canceling are kept. The select-all box on a group, site or folder row ticks every run shown under it. A deleted row is first marked Deleted. SMART Migration picks it up on its next check, purges that run's data from the reporting database, and then the row is removed for good — together with the run's file issues, its session log once no other run shares it, and its folder in Nextcloud Files. A Job Import run feeds no reporting and is removed at once. Every delete confirmation says this, step by step. Delete group on a group row goes further: it deletes the group with its jobs and its runs — see Groups and tags

A run purges only the files it still holds

In the BI data, a file belongs to the run that last reported it. If run 1 found 10 files and run 2 found 3 of them changed, deleting run 1 purges only 7 — the 3 changed files stay with run 2.

Refresh the Power BI report after deleting

Until SMART Migration has purged the deleted runs, the Dashboard's Power BI heading shows that the Business Intelligence data is catching up. The report itself changes only when SMART BI.pbix is refreshed in Power BI Desktop: refresh it, save it and upload it again once that has cleared.

Delete old runs automatically: the retention schedule

A job that runs often — every day, or again and again before go-live — leaves a run each time. Its Retention schedule deletes those runs once they are old enough, so Run History keeps what is still worth reading without anyone deleting by hand. It is housekeeping, not a need of the server: a long Run History costs Nextcloud little — see Performance and load on the Nextcloud server.

Set it in the job dialog, on the Job step in Advanced Settings, after Recurrence: Keep every run (the default), or Days, Weeks, Months or Years and how many of them — 1 to 999 — a run is kept after it finished.

Checked every hour by the app itself, inside Nextcloud: every run of the job that finished longer ago than the schedule allows is deleted.
Deleted the same way as Delete … deletes: marked Deleted, purged from the reporting database by SMART Migration on its next check, then removed for good with its file issues and its folder. A Job Import run is removed at once.
Kept: a pinned run, whatever its age, and a run still Running or Canceling. An archived run is not kept: archiving does not protect it.
Hidden only: with Advanced Settings off, the schedule stays in force; the job's summary card shows it as Retention schedule.

A retention schedule takes the runs out of the BI report

Each run the schedule deletes leaves the Business Intelligence data as well, as a run deleted by hand does. Pin a run to keep it, or archive the runs instead of setting a schedule when the report should keep counting them.

Important: the Dashboard's figures change only once SMART Migration has purged the runs. Refresh the report when the Power BI heading on the Dashboard shows a green Up to date instead of a red mark.

See also