It would be a very useful feature for both developers and users in list views to be able to see the underlying field name (and path to the field, in cases of forwards references) of a column. Currently, for regular columns (not aggregations) you can only see the current name of the column as set up by the developer or the user, if they've customised the name. But this hides information about where that value is actually coming from, making it harder to understand the origin of the data, for example if the user wanted to set up folder filters where they would have to be using the field names in the actual object configuration.

At the moment, this is the only information visible to users for a basic list column's properties, which could have been renamed by either a developer or the user themselves:

Currently, as a developer I need to check in the dev tools' network tab to get the column name and path in the request, then check the object's configuration to find what that field is captioned with. Or check in the page's code to find the configuration that was set up. Neither of these are very user friendly.

Ideally, the properties popup would be enriched with information about the origin of the data similar to what you would see when setting up a dynamic folder as can be seen here:

It would be very useful for many scenarios to be have the "old" (pre-change) values passed into Business Processes triggered by either data updates or deletions. This is possible to get when using Entity Event Listeners, so it seems like the data should be readily available to Business Processes without much overhead, and would unlock a lot of abilities to do via no-code tools that currently are only achievable using C# code or workarounds.

The way I see it working is that the triggered start would be passed in every field value of the old record, which the user could use in the process in the same way users can currently the Id of the changed/deleted record.

Use cases that I've come across:

1. Updating permissions to revoke permissions granted based on the record's old value (currently would either have to be done via code or by revoking all permissions and re-granting the specific ones, which in complicated permissions setups can be very costly to perform and can potentially lead to issues)
2. Sending updates to external systems about the removal of data
3. Updating an automatically-set field that can also be modified by a user directly to see if the old value was automatically set or manually set by the user (by checking if the value matches the automatic construction using the old data)
4. Checking time differences between events without having to build a completely separate logging table

I'm sure there are many more use cases that the community could provide too, as this is a problem I often face and have to find workarounds for or go through the process of creating an Entity Event Listener.

A few Creatio Community posts requesting similar functionality:

• https://community.creatio.com/questions/how-read-pre-change-values-business-process
• https://community.creatio.com/questions/compare-product-price-value-and-after-update
• https://community.creatio.com/questions/read-old-column-value-bp

Hello everyone, 

I would like to suggest adding a "Feedback" button directly on Academy pages. 

As a simple example of the kind of issue this would help surface: The Academy article "Add a campaign" (Creatio 8.3+) contains hyperlinks redirecting to Academy Articles intended for Creatio Version 7.18, as well as completely different articles being referenced for "Campaign Diagram" within the body (-> Campaign element reference, 7.18) and the bottom section (-> Set up campaign diagram, 8.3) of the Article.

Currently, the only way known to me to report issues or suggestions is to leave the Academy page and send a separate email to Creatio Support manually - a step that likely discourages many users from contributing.

An in-page feedback option would lower that barrier significantly and make it much easier for users to flag such issues, ultimately benefiting both the community and the Academy team.

Best,
David

Hi,

It would be extremely valuable to allow manual axis limits on charts (Y-axis and/or X-axis), instead of only dynamic scaling.

For example, if a company has a monthly revenue target of 100K, users should be able to:

• Set a fixed Y-axis range (e.g., 0 → 200K),
• Define visual milestones (e.g., 50K, 100K, 150K),
• Add a target line representing the goal.

This becomes critical when comparing performance across periods or segments.

Today, charts automatically rescale based on the data. While convenient, this makes visual comparison unreliable.
For instance:

• Year A: 20K per month
• Year B: 400K per month

Both graphs appear visually similar because each uses dynamic scaling, which defeats the purpose of comparison.

Fixed scaling ensures that:

• Year-over-year comparisons are meaningful
• Multiple product lines or segments can be evaluated consistently
• Performance gaps are immediately visible
• Targets and progress are easier to communicate to stakeholders

Additionally, the ability to add a static target/goal line would significantly improve usability for sales and management dashboards. This is already a standard feature in many tools (e.g., Pipedrive and others for years).

In short, fixed axis controls + target lines would materially improve analytical accuracy and decision-making.

Thank you for considering this enhancement.

Creatio has the ability in charts to set "top N" limits for dashboard widgets like bar and column charts through the code, by modifying the rowCount property (path config > series > data > providing > rowCount) but this property isn't surfaced via the Page Designer UI. This is often a very useful feature, and so it would be good to make it possible to set it via the Page Designer UI to reduce the need to make page code changes.

At the moment, it seems like the Page Designer can quite easily accidentally override the rowCount value by changing small config settings in the graph as well, which is bad for causing regressions. If this were surfaced in the Page Designer, this would presumably resolve this issue too.