Version History v11 vs. v12

Hi everyone,

We as well as other customers are frequently asking for the version history in v11 to be implemented in v12. There were various of enhancement requests regarding this topic and all of them were supported highly by a lot of different customers.

In Frankfurt we discussed this topic with @nick-gladkov and @kristian-ujlaki as it is a big topic for on-premise customers. If I understand it correctly, the issue with recovering an old report status is, that global list etc. maybe have changed in-between and therefore setting back a report could lead to troubles.

We as a customer are aware of that point and normally don't go back so far in history that this troubles us. Reasons for going back from our side:

I have to save a development state of a report, to see e. g. web extensions working in the web => no possibility to jump back
Testing something and go directly back to the previous state because the user found issues with the new version
See in a small comment, what was changed last time and now maybe causes issues
Jump back to see the formula/action/... that was changed before. Then using the current report to find a solution for an upcoming issue.
...

I know that still a lot of customers are awaiting this feature (on-premise). So I am sad that enhancement requests regarding to this topic are just closed as "Will not be implemented" without any comment why.

@kristian-ujlaki can you please give more insights in that topic, to get a better understanding on both sides.

@Customers & Partners: How do you use this feature and why do you need it?

Thanks in advance,

Sylvana

Find more posts tagged with

Infor EPM Discussions

Comments

Malte Reiff

Hi all,

From our perspective this is clearly a feature, we are missing. We used it for the same purposes Sylvana has described.

In addition, we used it for audit purposes to prove that a report has not been modified after it has been created, tested and moved to production. All changes to a report had to be documented and could be tracked in the system.

TBH I don't think it will be an issue for any developer, that reports might not work anymore, if the datasource or any global lists have changed. This behaviour is true for any other system as well, where versioning is a standard.

I do understand, that development resources have to spent where they create the highest benefit. But this feature has a high benefit for many customers that have reached a certain level of maturity. It is unclear to me, why more audit features are implemented in the system in various places but versioning in App Studio will not be implemented. We clearly need both.

Best regards,
Malte

gottesheim-daniela

Hello,

I agree to what has already been said regarding version history in v12. When we migrated from v11 to v12, that was one of the biggest missing features we had to deal with.
It happens so quickly that something on a reports gets changed and checked-in and then there is no way back to the original version of the report. A report developer would need to do that manually, which is not user-friendly.
From a developers point of view I don't need to have a full restore of all lists which are used on the report, but at least the original report definition would be great.

In addition, I want to mention that I find it quite hard to understand why some ERs are just closed with "will not be implemented", but there is no further explanation or clarification why it has been denied. It would help to get more insight on the reasons for the denial.

Best regards, Daniela

fabian-muhn

Hello,

actually we are using V11. We are already on a POC in our company for V12.

We are really missing this feature, too.

The reasons are the same like in the prev. posts.

Best Regards

Fabian

fabian-muhn

If you have a look here

https://docs.infor.com/depm/2025.x/en-us/depmolh/default.html?helpcontent=migration/esg1522789020342.html&hl=removed%2Cfeatures

There is a feature planned.

But for the time being, I cannot verify, if this is still up to date.

Best Regards

Fabian

Nick Gladkov

Thanks, Sylvana, and another thank you for sumarizing the points!

At the moment the plan for the next 12-24 months is the following:

1. Later this year (currently planned for April 2025), we are adding new properties to Reports in Application Studio, so you can always see the date and user of the last report change. This was identified by many customers as the most critical point as there was no clarify if report was changed (yes/no), when and by whom. @sneydek I think it was also confirmed with you.

2. We do not have plans to bring reporting copies in the foreseeable future based on the current priorities and the conversations we had with our user community.

3. New idea - we can think about bringing optional comment during the checkin - would you think this might be good mid-term solution for the topic?

fabian-muhn

Dear Nick,

the last change user, if the report was changed (yes/no) or comment doesn't help us.

We need to able to jump between versions and restore them quickly within our development cycle.

Fabian

zsolt-pinter

Hello Sylvana / Nick,

Thanks for raising it! Actually, I think the reason why it is so critical for many people, is that although in V12 there is a development and a production environment separated, as per my best knowledge there is not (yet) an easy way to securely and automatically deploy content from development to production, also in a documented and tracable way. Currently, unless it is a really major change, all the day to day changes we develop and deploy in fact within the production environment, that's why the version history gives a certain level of security. If things turn out to be not working, or we mess up the report while changing it, there is always and easy plan B by reverting to the previous version.

I believe that a more solid (and documented) deployment workflow would be a good alternative, if there is anything like this on the roadmap. In this case, backups of the development environment could replace any version history. It would even be better, because it wouldn't only secure the reports, but also the OLAP database etc...

Thanks a lot! Zsolt

Nick Gladkov

Zsolt, the reality is that report history is not helping you with that, say you added new actions, processes, linked variables and lists to report in a new version. Now, by coming back to the previous report version you won't cancel all of that as it is covering only small part of Application Studio world.

As regards to the movement of reports between test and dev - this is one of the easiest things and the April release is bringing new major changes of moving content between environments. With the 2024.04 release we adding option to move packages containing all essential parts of your applications - so you can package reports, processes, OLAP objects, relational objects - all by picking all, none of part of the current model. We will publish the April release overview soon, so you can find more details.

Copyright © 2025 Infor. All rights reserved.