Today, modern reports must be designed for more than just one purpose. In addition, "all" data should be contained as simply as possible – but presented in a clear and structured way. With List & Label such multifunctional reports can be easily realized. Interactive elements allow a single report to cover several scenarios, while selection options further enhance the report. This makes reports more comprehensive and informative and can be easily operated by the user.
This is another great addition to the report container's feature set. Until LL25, related tables always needed to have an actual relation on the data source level in order to be usable as data source for sub items. If there was no relation, there was no way to insert the sub item, even if both tables in question had an ID field that would easily allow a custom linkage. In LL25, you can now have relations based on filter conditions.
List & Label's powerful filter options could not be used for all data sources so far. Reason is, especially for web based data sources, it is not possible or feasible to get "all" data first and then filter to the desired subset. The upcoming version 24 comes with a powerful new feature that addresses this very issue: Parametrized Data Sources. It allows to combine data source parameters with actual report parameters in the Designer.
No matter which data, using the DataProvider interface you can write your own custom binding. And of course we ship a whole family of providers with List & Label. In LL23, there's a new member of this family that allows your applications to connect to Salesforce data easily.
The .NET DataProvider concept allows to bind to almost any data source. Basically, it mimics a relational database management system containing tables, relations, sort orders etc. However, often you'll find yourself needing to combine data from different sources, e.g. a server log file that contains customer logins and a SQL customer database that contains all pertinent information about the customers.
Using report parameters has become very popular since we've introduced them in version 19. A typical use case that will become even more seminal with version 20 of our reporting tool is using parameters to filter data (see last feature focus). This is something we've usually put on the "don't" list as databases can filter data much faster than we can. In the past, all records had to be passed to the reporting engine which then decided if a record should be used or not. A vast overhead for a task databases are usually optimized for. In version 20, we'll be introducing a new feature that allows List & Label filter expressions to be translated to native database filters, therefore hugely increasing performance (in principle, depending on the data this is "infinitely" faster).