Lifecycle status update fails in Fiori app with 'Insufficient authorization' error for workflow step

PLM SAP PLM
, , , , , , , ,
1

We’re experiencing authorization failures when users attempt to update product lifecycle status from ‘In Design’ to ‘In Review’ through the Fiori app. The same users can perform identical updates successfully in SAP GUI, but the Fiori interface throws ‘Insufficient Authorization’ errors.

Error in browser console:


HTTP 403: Authorization check failed
OData service: /sap/opu/odata/SAP/PLM_LIFECYCLE_SRV
Entity: LifecycleStatusSet
Operation: UPDATE

I’ve verified the PFCG roles include standard lifecycle management authorizations, and the OData service is activated. The authorization trace shows the check passes in GUI but fails in Fiori. Has anyone encountered discrepancies between Fiori and GUI permission models for lifecycle operations? What additional authorization objects or service-specific settings might be required?

2

Your issue requires addressing all three authorization layers: OData service permissions, PFCG role adjustments, and the permission model differences between Fiori and SAP GUI.

OData Service Authorization Layer: The OData service /sap/opu/odata/SAP/PLM_LIFECYCLE_SRV requires explicit authorization beyond functional permissions. Add these authorization objects to your roles:


S_SERVICE: TADIR_TYPE=IWSG, NAME=PLM_LIFECYCLE_SRV
S_ICF: ICF_VALUE=/sap/opu/odata/sap/plm_lifecycle_srv*

These grant access to the service definition and ICF node respectively.

PFCG Role Adjustment: Fiori enforces operation-level authorization on OData entity sets. Your roles need S_TABU_NAM or custom authorization objects with ACTVT values for each operation. For lifecycle status updates, ensure:

  • ACTVT 02 (Change) on the LifecycleStatusSet entity
  • Authorization for the target status value in object C_STPO_STA
  • Workflow authorization if status changes trigger approval workflows (object WF_WI_STAT)

Create a derived role from SAP_PLM_LIFECYCLE_MANAGER and add these objects explicitly.

Fiori vs SAP GUI Permission Model: The key difference is that Fiori apps perform authorization checks at the OData service layer BEFORE reaching business logic, while GUI transactions check during business logic execution. This means:

  1. GUI might perform authorization checks after default values are set
  2. Fiori checks occur on the raw input data before preprocessing
  3. Field-level authorization is stricter in OData (every field in the payload is checked)

To resolve:

  1. Run SU53 immediately after Fiori error to identify the failing authorization object
  2. Execute ST01 trace for both GUI and Fiori sessions, comparing authorization check sequences
  3. Use /IWFND/ERROR_LOG to review detailed OData error messages including authorization context
  4. Test with SAP_ALL temporarily to confirm it’s purely authorization-related
  5. Add the identified authorization objects to your custom role incrementally

Common resolution: Adding S_SERVICE with appropriate values and ensuring ACTVT 02 exists for status field authorizations typically resolves 80% of these cases. The remaining 20% require custom authorization object maintenance if your implementation uses extended authorization checks in the OData service implementation class.

3

Classic OData authorization gap. Fiori apps use different authorization paths than GUI transactions. Check if your PFCG roles include the S_SERVICE authorization object with appropriate values for the OData service. The GUI authorization check might pass on transaction codes alone, but OData requires explicit service-level permissions.

4

Check the /IWFND/ERROR_LOG transaction for detailed OData error traces. In our implementation, we discovered that Fiori lifecycle updates trigger additional workflow authorization checks that GUI bypasses. The workflow service user needs proper delegation rights.

5

Have you compared the authorization traces between GUI and Fiori sessions? Use ST01 with authorization check filter for both scenarios. I suspect the OData service is performing field-level authorization checks that the GUI transaction doesn’t enforce. Specifically, look for authorization object C_STPO_BES with activity 02 (change) and the specific status field authorizations. In SAP PLM 2022, Fiori apps often enforce stricter field-level security than their GUI counterparts, particularly for status transitions that might trigger downstream processes or notifications.

6

This sounds like a service binding authorization issue. The OData service metadata might define authorization requirements that aren’t mapped to your existing PFCG roles. Navigate to /IWFND/MAINT_SERVICE and check the service’s technical settings and authorization defaults.