We’re running into a persistent authorization issue with our payroll CI/CD pipeline. The automated transport import step fails consistently despite proper user setup.
Our Jenkins pipeline connects to SAP S/4HANA 1809 using a technical user that has SAP_ALL assigned. The transport moves through DEV and QA environments without issues, but production import fails at the authorization check:
Error: TP_AUTHORIZATION_FAILURE
User JENKINS_TECH does not have authorization for import
Transaction: STMS_IMPORT, Object: S_TRANSPRT
What’s puzzling is the user has SAP_ALL, which should cover all authorizations. We’ve verified the profile is active and properly assigned in SU01. The same credentials work fine for manual transports through STMS.
Anyone encountered this with automated payroll deployments? Are there specific authorization objects beyond SAP_ALL needed for programmatic transport imports?
We had this exact scenario last year. The root cause was that STMS transport imports triggered via RFC require authorization for the original transport owner, not just the importing user. Check STMS configuration in transaction STMS > System Overview > Transport Tool. Look for the ‘Authorization Check’ settings. You might need to add your Jenkins technical user to the ‘Authorized Users’ list for import operations specifically. Also verify that the transport domain controller settings allow automated imports from your pipeline’s source system.
SAP_ALL is actually not recommended for automated processes due to audit and compliance concerns. Instead, create a composite role with specific authorization objects. For your pipeline, you need S_TRANSPRT with activities 01, 02, 23, and 78. Also add S_TOOLS_EX for extended tool access and S_RFC for remote function call execution. Document these specific authorizations for your auditors. This approach also helps isolate what permissions your automation actually needs versus blanket admin access.
This is a known limitation with STMS automation. The authorization check for programmatic imports differs from manual execution. You need to ensure:
- The technical user has S_TRANSPRT with activity 78 (import with original user)
- Background processing authorization S_BTCH_JOB is properly configured
- The import queue owner settings in STMS allow your technical user
Even with SAP_ALL, these specific authorization contexts can be blocked. Check transaction SU53 immediately after the failed import to see exactly which authorization object is missing. In payroll scenarios, there might be additional HR-specific authorization objects required. Have you checked S_PLOG for payroll-specific transport authorizations?
Payroll transports have additional security layers. Beyond standard transport authorizations, check if your production system has enhanced change control enabled (transaction SCCL). This can block automated imports even with correct authorizations. We had to whitelist our CI/CD user in the change control configuration. Also, payroll-specific authorization object P_ORGIN might be involved if your transports contain payroll schema or rule customizing.
I’ve seen this before. SAP_ALL doesn’t always cover system-level operations in automated contexts. Check if your technical user has S_RFCACL with the right activity values. Also verify the RFC destination used by Jenkins has proper authorization assignments in SM59. Sometimes the authorization check happens at the RFC layer, not just the user level.