Groups and tags

Job Group

One per job, or none. In practice the migration wave — Pilot, Wave 1, Finance. The Jobs, Run History and File Issues trees are organised by it, and it is replicated into the Power BI report.

Groups: migration waves

Every job belongs to one group or to none, set as Job Group on the Job step of the job dialog, or in the Group column of the Jobs table. The trees on the Jobs, Run History and File Issues tabs show each group as a band of its own, with the number of jobs or runs in it. On the Jobs tab, rest the pointer on a group's name for its card: its jobs per status, mode and source type, the next run's date and the job that runs then, the last run's date, its mode and which run it was, and a section per mode its runs ran in — a Discovery section with what the jobs' latest Discovery runs found, a job counted once, and a Migration or Test Migration section with the files, versions and volume their runs moved, added up.

Manage groups, in the ⋯ menu at the far right of the Jobs, Run History and File Issues tab bars, adds, renames, recolours, merges and deletes groups:

Add group — a name, up to 50 characters, and a colour.
Rename — the new name shows on every job and run in the group. A run keeps the group's name, so it still says where it was filed should the group be removed.
Merge into … — moves every job of one group into another, then deletes the first. It cannot be undone.
Delete — the group's jobs stay, with no group.

Manage groups beside a group field — Job Group and Import Group in the job dialog, the Group field of Change selected jobs …, and a click on a job's group in the Group column of the Jobs table — also picks the field's group. From the Group column, the chosen group goes to that job, or to every selected job when the row is part of a selection. The dialog opens as Select or edit groups, with a choice in front of every group and one for no group, starting on the field's own group. Click a row to choose it; a group you add is chosen at once. Save and select saves the changes to the groups and puts the chosen group in the field — with no group chosen the button reads Save, and the field is left with no group. Cancel leaves both as they were. Only the list of groups scrolls; the New group field stays in view above it.

The group row of the Jobs, Run History and File Issues trees has Rename group and Delete group on its ⋯ menu too; to change every job in a group, tick its box and use the Actions menu: see Change many jobs at once

Delete group on a group row deletes everything in it

Unlike Delete in Manage groups, Delete group on a group row deletes the group together with every job filed under it and every Run History row filed under it. The confirmation counts both and asks you to tick that you understand before it will. The deleted runs are taken out of the Business Intelligence data as any deleted run is — the Dashboard shows when that is done — and the jobs cannot be brought back. It is refused while SMART Migration is working on any of them, or one of the jobs is Ready and may be claimed.

Read more about deleted runs and the report: Run History

Imports arrive in a group of their own

Every Import job files the jobs it creates in a new group: the group chosen as Import Group, followed by the date and time the import started, such as Wave 1 2027-01-20 14:05. Check the new jobs there, then merge the group into the one they belong to with Manage groups.

A job's runs and its group

Each run is filed under the group its job had when it ran. When you change a job's group — in the Group column, the job dialog, Move to group, Change selected jobs … or by dragging it in the tree — and some of its runs are in another group, the app asks whether they should move with it: Yes, move them files them under the job's new group, No, keep their group leaves them where they are. A run still under way always follows its job. Runs that move take their new group into the BI report too: SMART Migration writes it into the BI data on its next check, and until then the mark on the Dashboard's Power BI heading is amber and says how many changed runs are still to be updated.

A run's group is its own record, as its tags are: change it later, run by run, with Job Group in the run's details on the Run History tab, or for several runs with Change selected runs … in the Actions menu. Its job keeps its own group, and a later run takes the job's group as it is then.

Filter by group

The Group filter, under the Group column's title, shows the rows of any of the groups picked; <None> picks the rows without one — what the tables show, greyed out, for a job or run with no group. The choice is shared by the Jobs, Run History and File Issues tabs, so one wave can be followed from its jobs to their runs and their file issues.

Tags: labels across the groups

Tags are set as Tags on the Job step of the job dialog, or right in the Tags column of the Jobs table: type a tag and press Enter. The tables show a row's tags on one line, with a … when more do not fit; rest the pointer on them to see them all. A tag is at most 50 characters and holds no comma.

Filter by Tags shows the rows that carry every tag picked.
Each run keeps the tags its job had when it ran, so Run History still says what a job was labelled at the time.
A run's own tags can be edited in the Tags column of Run History, or with Change selected runs … in the row menu or the Actions menu for two or more ticked runs. Only the run's record changes: its job keeps its tags, and a later run takes the job's tags as they are then.
Set, Merge or Remove decides what the tags listed do when several jobs or runs are changed at once, in Change selected jobs …, Change selected runs … and Edit tags: Set gives every row exactly those tags, Merge adds them to each row's own, and Remove takes them off each row and keeps the rest. When the tags listed would change nothing — every row has them already, none has the ones to take off, or every row has exactly those — a green line under the box says so, and Apply waits.
Manage tags, in the same ⋯ menu, adds, renames, recolours or deletes a tag on every job that carries it; type a name under New tag and Add tag to create one before any job carries it; click a dot to change a tag's colour. Renaming a tag to one already in use merges the two.
Manage tags beside a Tags field in the job dialog or the run's details also picks the field's tags: tick them and Save and select. A tag you add there is ticked at once. From the ⋯ menu it only manages.
Manage tags renames, merges and deletes a tag on every job and on every run that carries it, as tags are global. A tag stays in the list when no job or run carries it any more, until you delete it there.
A run's new tags, group or name reach the BI report once SMART Migration has written them into the BI data, on its next check — whether changed on the run, in Manage tags or by renaming a group its runs are filed under. The Dashboard's Power BI heading shows an amber mark while changed runs are still to be updated. Refresh SMART BI.pbix after that. See Refresh, upload and share SMART BI.pbix

Groups, tags and Archived together

A group says which wave a job belongs to; a tag says which piece of work it is part of, across the waves — a department, an owner, a cut-over weekend, or the state of the work, such as Needs review or Signed off. Filter the Jobs, Run History and Dashboard tables by that tag to follow the piece of work from its jobs to how their runs ended. Write in My note what you must remember about one job, run or issue — the note is your own, and the text filter finds it. When it is done, archive its jobs and their runs: they leave the everyday views and stay in the record and the report. See Monitor the migration from one place

Groups and tags in the Power BI report

The job's group is carried into the reporting database with every run, so the Power BI report can show the migration wave by wave. See Business intelligence with Power BI

See also

For how groups, tags, pins, My note and the archive work together in a project, with patterns to copy, see Organise the jobs of a project