Introduction: The perfect crime

It was a perfectly ordinary Monday in SAP GRC 12.0 (SP 23).
The user created an access request, clicked Send and received the standard confirmation:

“Application sent successfully. Application number: 12345.”

Nothing looked suspicious. The user returned to his duties.
Meanwhile, the Acceptor’s mailbox remained empty. A search for requests returned the message “No records found.”

After checking the GRACREQ tables, the last saved application had the number 12344.
A new number, 12345, was retrieved from the numbering range – but was never saved in the database.

The proposal didn’t end in error.
He just… evaporated.

This is one of those mistakes that can eat up half a day’s work for the GRC team. The worst part was that the system lied – calmly and with full conviction.

Analysis: The certainty of the interface versus the reality of the backend

At first glance, it looked like user error.
However, screenshots quickly showed that the interface confirmed success every time.

Only analysis of backend logs began to reveal the truth.
A key message appeared in ST22 and SM21:

“No RFC authorization for the function module GRAC_AR_UPDATE_REQUEST.”

No popup. No warning. Just a silent denial on the backend side.

What was really going on

The system recently underwent a kernel update.
This change introduced stricter RFC authorization controls inside the GRC application process.

The process was as follows:

• The UI interface initiated the creation of the application.
• The system generated a new application number from the numbering range.
• When attempting to write data via GRAC_AR_UPDATE_REQUEST, the kernel performed an RFC permission check.
• The user role did not have the required S_RFC object.
• The write failed, but the interface did not handle the exception and still displayed a success message, based only on the process call itself.

As a result, the number was “used up,” the data was not saved, and the user did not get any information.

Why we didn’t detect it in tests (Firefighter trap)

Why didn’t the problem come up during the UAT?

The administrator tried to reproduce it – and saw no error. Everything worked fine.
The reason turned out to be trivial, though painful.

He tested on Firefighter ID.

Firefighter roles typically have very broad permissions, often including RFC objects that regular users do not have.
These additional powers completely masked the lack of authorization.

Lesson learned:
Never test end-user errors with an account with administrator privileges.
If you want real results, use a test user with an identical copy of the business role. SU53 will do the rest.

Solution

This behavior is described in SAP Note 3694152.

The solution was simple, once we knew the cause:
end-user roles had to be extended with the explicit GRAC_AR_UPDATE_REQUEST function module permission in the S_RFC object.

After transporting the role changes from DEV to QAS and PRD, the requests stopped disappearing.
The interface and database started saying the same thing again.

Summary

If you are using SAP GRC 12.0 and have recently updated the kernel, it is worth checking.

Take a look at ST22 right after user reports of disappearing applications.
Test on users with limited privileges, not Firefighters.
And be sure to review SAP Note 3694152 – especially if the system has become suspiciously “quiet” after the update.

Details have been anonymized. Case based on real customer problem.

If you work with GRC systems after updates, such situations happen more often than you might think 🙂