Skip to Content

Why does not SAP keep change history of a role when it is overwritten by a transport request?

Sep 13, 2017 at 07:05 AM


avatar image


I realised that SAP does not keep any change history for a role when the role is transported to test and production systems with a request.

So users complain about lack of authorisations that they had yesterday but not today. I see that they run that transaction yesterday but they have SU53 that is showing missing transaction auth now.

I investigated all kinds of chnage history but no track of change in any user and roles change history. After a while I learned that some other guys changed the role in development system and transported it to the production system.

Don't you think SAP must keep a line in a change history for this imported request keeping the role?



10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Colleen Hebbert
Sep 13, 2017 at 08:02 AM

authorisation changes are in the system they are made it. So check dev client for pfcg change. If you see a change in prod someone either directly updated the role, uploaded it or generated the profile.

User assignments are stored in each system

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Hello Colleen,

Someone has changed the role in production system and users had the authorisation. This means roles are different in dev and prod system now.

The other security guy has changed the role in development system and transported the role to production system. With this import the required authorisation is lost.

When I check the change history in production system I cannot see the role change done by the request import.

In my opinion the role change history must involve this import history as it is seen as version history for other dictionary objects.




Hi Yuksel

Really your security person should have avoided making configuration changes directly in production. If SU24 configuration is different between the two systems you are already as risk of losing (or gaining) access in your production roles It would have been avoided.

If they did update Production then they should have immediately manually applied those same changes to development to avoid them being lost.

The change documents are where the change was actioned. I can imagine the transport size and performance issues could be an issue if you were trying to calculated change documents on each import step.

You can identify the gaps by running change documents in Production for authorisations to see what the person directly added or removed and then check development to see if those authorisations are there.