As some of the changes might be done by a procedure schedule through a SQL agent job, it would be very helpfull if a filter could be applied to ignore changes made by specific users.

For example we have a changeset like:

Version 1.3: Add Missing Indexes

And this script would be run on all pipelines but each Schema drift would have to be named differently which is just confusing for users it would be great to see the same name in each pipeline for the same changeset.

When reviewing a drift in sprocs running hundreds of lines of code, it is hard to find the line that changed because the UI presents the full file with no links or shortcuts to the changes. Since the full SQL statement is available as a download, the UI should only show the changed lines and maybe +3 lines above or below for context.

I have installed a filter that excludes all User and Role changes. However, a SQL GRANT EXECUTE TO user statement appears as an Update. The type is Unknown. Is it possible to filter these out as well?

So we have specific groups that work on certain projects/pipelines. The ability to configure email notification groups based on the pipeline there're working on would be awesome i.e. group A working on pipeline A only gets pipeline A drift notifications. Group B working on pipeline B only gets pipeline B drift notifications

show find change history of single objects, (who, when and what has changed on an explicit object.)

It would be great if the hostname who made the change was included, incase people use the same login name. We have developers who all use the same login e.g. developer so seeing who made the change is not possible, as it says login name developer but can it also include hostname e.g. pauls-laptop

It would be nice to have an option to ignore column order and index order

I'd like to be able to sort the drifts to the top of the dashboard instead of always having them in alphabetical order. I believe that the reason you are going to the dashboard is to see the drifts, so they're the most important items and I'd like to see mine up top instead of scrolling down to find them all.

Add a filter option for jobs by APP_NAME

Allow DLM Dashboard to seamlessly support databases that are in Availability Groups.

Currently, you have to create the objects on one server, then fail the AG over to the other servers, and recreate the objects there. Otherwise, when the AG is failed over, DLM has problems.

Ideally, this process would be seamless, behind-the-scenes (or maybe with a prompt to the user configuring the DB for use with DLM Dashboard to indicate that the DB is part of an AG, and therefore the process will also run against the other servers).

(Logged off the back of a support ticket 55607)

Please expand the filter documentation to have an example for each type of filter available.

Also, allow me to filter out those changes that are listed as " The object may have been rolled back." We drop indexes and then rebuild indexes as part of daily data loads. I don't need to see this in the list.

Currently when we see a new table, the NVARCHAR columns also specify the collation that they are using. If the collation was not specified and the default is being used, I would like to not see the collation in the diff shown in the dashboard.

This is likely an issue in more places than just new tables, likely other spots with (N)VARCHAR columns.

On all tabs, particularly the Home tab, there is way too much wasted screen real estate. On my 1920*1080 resolution monitor, I can see a whopping 2.5 rows (pipelines) at once. That's ridiculous.

Offline Databases show up in the "Add Databases View" - show a hint or remove offline DB's from the list

I would like to be able to bulk acknowledge the same changes made to multiple databases in a pipeline.

On the dashboard you can see how many changes that has been done by a particular user in a database. I think it would be great if you could filter the view on changes per user in the same way as another suggestion posted here: that you should be able to filter the dashboard on object level.