The popup list you get when clicking on widgets should be configurable in the Page Designer. Currently you get a default list based on the object and the metric you clicked on, which is a decent starting point, but most of the time is not the full picture you would want for users to see. Configuring this in Creatio currently is fairly tedious and has some shortcomings I would like to see improved.

The list setup also becomes locked for all widgets based on the same object if a user even adjusts the column widths of that list; so the list for a metric widget based on Bulk Emails for a sum of Delivered (which would show the bulk email name and the individual Delivered counts by default) would show that same list for a metric widget based on Bulk Emails for a sum of Opened, which is not great for the user experience.

To address these shortcomings, I would like to see this list config be configurable within the Page Designer for the page they are on. I would picture this as a button in the right side config panel when selecting the widget, which pops up what you would see when a user clicks the widget and allows you to put the columns and sorting etc on it, somewhat similar to how you get a popup for the chart designer on a page where you can save or cancel changes. Adding this to the side panel would be a good opportunity to expose the option to disable clicking on the widget to get the list popup, which is currently only possible via page code.

I would also like there to be new granularity of the widget list setup as part of this, so that you can specify that this widget list is just for one specific widget or make it the default for all widgets based on that object for all users (the latter being the way it currently is for users, since the SysProfileData Key is like "AnalyticsColumns_BulkEmail"). I would picture this as being a dropdown/similar on the popup in the Page Designer, allowing the developer to switch from using the object's default (which you could change and save in Page Designer, updating the default across Creatio and binding it to the same package as the page you're editing) to using a custom list setup specifically for that one widget on the page.

A quick AI mock up of what I was thinking of:

My experience is that 90% of the cases you will not want the users to add values to lookups or list components directly on the page.
The default value should be false or at least a system setting

Some filters in BP steps such as the Read, Modify and Delete Data steps do not currently allow parameterisation of the filters, which can be a real constraint on development, often requiring workarounds or using a Script Task instead. It would be very useful to add in this functionality, similar to how most other filters can take the value from a parameter.

One example is in the Date macro filters for Previous X days, Following X days, Year X, Every year within X next days and so on. These all require a hard-coded number to be entered with no option to select a parameter/previous step's output for these values:

Often this reference data is stored somewhere and may want to change without having clients doing development, but at the moment this is not possible. Please can this feature be added to bring these types of filter in line with other filters on the same steps which do allow for passing in a parameter?

It would be nice if there was some automatic prompt to the user in the app hub when exporting a customer application to update the version number of a customer application. Just a little popup asking if you would like specify the version number, showing the current version number, would make this feature a lot more visible & easy to incorporate into standard workflows.

When adding code into a page that has to call crt.ClosePageRequest to close the page in the code, it's a very common pattern to want to close the page without the standard dialog prompt to the user asking about unsaved changes appearing. It is possible to override the crt.CanDiscardUnsavedDataRequest handler to return true to do so, but most of the time you don't want this to happen for any close page event, just the one in your particular code path(s). This leads to somewhat over-complicated code to set an attribute so that the crt.CanDiscardUnsavedDataRequest handler can know if you've gone down this code path where it can be discarded or it's from some other source such as the user clicking to close the page, introducing possible bugs.

I would propose that it should be possible to pass in a parameter to the crt.ClosePageRequest call to specifically tell that handler whether it should discard the unsaved changes or not, defaulted to false so that current behaviour is maintained. This would look something like this in my view:

{
	"request": "usr.SomeHandler",
	"handler": async (request, next) => {
		// Some logic which decides that the page should be closed without saving
		
		// Close the page without prompting the user
		request.$context.executeRequest({
			type: "crt.ClosePageRequest",
			$context: request.$context,
			canDiscardUnsavedData: true
		});
		


		return next.handle(request);
	}
}

This is a lot more natural and clear what is happening, as all the logic is contained within the single handler's logic, and so doesn't require jumping to different handlers (which aren't obvious from just looking at the handler in question's code in the current ways of doing this) and unpicking that the code is preventing that popup elsewhere.