Save Report Filters

Going back into the stone age, report objects have always remembered the filter values for the next time that you run the report. What I never noticed was a capability to actually save filter values (yes I now realize that it’s been in there for years now). It’s similar to saving a view of a list page, but for reports. It works a little hinky but let me try and explain.

What I Am Talking About

You may have noticed it in some (but not all) reports, processing-only or actual printed ones. Right at the top of the request page, you see a dropdown box with the words “Last used options and filters”. Click the dropdown arrow and that should show you an option to “Select from full list”.

This opens the “Select – Report Settings” page. The page actually has nothing to do with any settings, but it does show you a list of saved values for the options and filters of the report object. In my mind I am calling it a ‘view’.

I just created a bogus empty report just to show you the options, so ignore the content of the report itself. The interesting part of this page is what you can do. When you click the ellipses, you get a number of options.

  • Delete – obviously to delete the currently selected option
  • New – creates a new record, where you can give the saved value a label and you can define whether this view is for all users or not. Assigning the view to a specific user is done on the list page itself
  • Copy – creates a new record with the same values as the one that’s called “Last used options and filters”
  • Edit – This only works on custom views, and it runs the report’s request page where you can enter the options and filter values for the current view

You can assign the view to a specific user or share it with all users. If this capability is enabled for a report, you should be able to pick from the list of views right from the request page.

How To Enable This

You need to do two things to enable this capability.

  • First, you set the ‘SaveValues’ property on the report’s requestpage. If the report doesn’t have a requestpage, you can add one with just the property and no controls
  • Second, you need to run the report. When you first deploy the report with SaveValues turned on, it does not yet have a view saved. Run the report with any filter/option value and it should create this record for you
requestpage
{
    SaveValues = true;
}

A Little Hinky

To me it feels a little unfinished, like it was rushed into the system. To begin, it’s inconsistent in labeling. On the requestpage it is called “Use default values from” which is incorrect. This is about ‘saved’ values, not ‘default’ values. Then when you open the full list, it is labeled “Select – Report Settings” which again doesn’t feel right. I don’t consider filter values a ‘setting’. Then when you click ‘New’ it opens a screen that is captioned “Edit – Pick Report”… I mean come on… Finally, having to run the report in order to even get the dropdown is not very user friendly. When I first tested this I thought I had done something wrong because the dropdown would not show.

Another big drawback is that the SaveValues property is not available in Report Extensions. You’ll have to copy the standard object in order to provide the capability.

Regardless of its hinkiness and shortcomings, the feature itself is great, especially when you have periodic activities to run for different sets of filters. it’s really nice to have the ability to preconfigure sets of option/filter values. It has the potential to increase productivity and eliminate typos in entering filters. In my opinion, this feature should be enabled by default.

Reports to Excel

Just a quick post about the new reporting capability to use Excel for the layout. It’s been out for a while now (it came out in v20 or 2022 wave 1), but there was a tweet earlier this year to point out some FAQs and some samples to get you started on it. Personally I haven’t had the time to really get into it but I wanted to share this so it doesn’t get lost.

Kind of a Big Deal

I have a feeling that this new capability is being underrated, to me this is really kind of a big deal. We all know how difficult it is to use RDLC, and I’ve been able to keep report development at a minimum. Now that we have the Excel layout as a new target, I can’t help but feel like this is the main direction that reporting will go (that and PowerBI of course, but that’s a whole other story). I would not be surprised if Excel will be playing a much more important role now that we can use it as the target for report objects.

OK so here’s the tweet, it was posted back in March and I had bookmarked it at the time to look at later.

What I think is really cool about the way some people in the BC team interact with the community, is that they will keep track of what the community is sharing, and actually promote these posts in their own documentation. Granted, the GitHub repo is no official documentation, but they DO link to community blog posts in there.

Like I said I still haven’t taken the time to dig in, but I wanted to get this posted not to lose the link. This will surely be enough to get started and get your feet wet with Excel Layouts.