User role missing access to approve formulas in recipe management after security redesign

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

After a recent security role redesign in our SAP PLM 2021 system, users assigned to the Recipe Approver role can no longer approve formulas in the recipe management module. They receive authorization errors when attempting to complete approval workflow steps.

I’ve checked with SUIM and SU53, and the authorization object checks are failing for what appears to be formula-specific approval actions. The role redesign was meant to consolidate several legacy roles into streamlined composite roles, but it seems we’ve lost some critical authorization mappings in the process.

The workflow itself is still triggering correctly and routing to the right users, but when they try to approve, the system blocks them. This is impacting our production recipe release cycle. Has anyone experienced similar issues after role consolidation? I need to understand which authorization objects specifically control formula approval in recipe management workflows.

2

The workflow approval logic in recipe management has dependencies on multiple authorization layers. First, there’s the workflow item authorization (S_SWWWIHEAD). Second, there’s the business object authorization for the formula object itself. Third, and this is often missed, there’s a specific authorization object for recipe approval actions that’s separate from general recipe access. When roles are consolidated, these multi-layer dependencies can break if not all objects are carried forward correctly.

3

Use SUIM transaction with the ‘Roles by Authorization Object’ report to compare what was in the old Recipe Approver role versus the new composite role. Pay special attention to authorization objects starting with C_ (for PLM) and S_SWW (for workflow). The authorization object mapping during consolidation might have missed some critical entries. Also check if there are any organizational level restrictions (like plant or company code) that got inadvertently tightened in the new role design.

4

I’ll walk you through the complete resolution based on your role redesign scenario:

Authorization Object Mapping Analysis: The formula approval in recipe management requires these specific authorization objects:

  1. S_SWWWIHEAD - Workflow item authorization

    • ACTVT: 16 (Execute workflow item)
    • WI_TYPE: F (workflow item type)

  2. C_STPO_MAR - BOM/Formula material authorization

    • ACTVT: 02 (Change) and 16 (Execute)
    • WERKS: Relevant plant codes
    • STLAN: BOM usage (typically 1 for material BOM, 4 for recipe)

  3. P_ORGIN - HR origin authorization (if recipe approval involves personnel data)

    • AUTHC: M (Master data)

  4. Custom authorization objects - Check for Z_RECIPE_* objects

    • Use SE16 on table AGR_1251 filtering by your old role name to find all custom objects

Role Redesign Impact Assessment: Compare the old and new roles systematically:

  1. Run SUIM → ‘Roles by Complex Selection Criteria’
  2. Export authorization data for both old Recipe Approver role and new composite role
  3. Use Excel or a comparison tool to identify missing authorization objects
  4. Pay attention to field-level values - sometimes the object exists but organizational restrictions (WERKS, BUKRS) are too narrow

Workflow Approval Logic Verification: The workflow routing works but approval fails because:

  1. Workflow task determination uses different authorization checks than approval execution
  2. Task TS00008267 (standard approval task) requires S_SWWWIHEAD with ACTVT=16
  3. The underlying business method (typically APPROVE or RELEASE) requires additional authorization on the formula business object

Resolution Steps:

  1. Immediate Fix - Add missing authorization objects to composite role:

    • Transaction PFCG → Open new composite role
    • Go to ‘Authorizations’ tab
    • Click ‘Change Authorization Data’
    • Manually add the authorization objects identified from old role comparison
    • For C_STPO_MAR, ensure STLAN includes value ‘4’ (recipe/formula)
    • For S_SWWWIHEAD, ensure ACTVT includes ‘16’
    • Generate the profile and assign to users

  2. Validation - Test with affected user:

    • Have user log out and back in (new authorizations take effect)
    • Attempt formula approval
    • If still failing, run SU53 immediately and note the exact object/field/value combination that’s missing

  3. Long-term Fix - Update role design methodology:

    • Create authorization matrix documenting all workflow-approval combinations
    • Include workflow simulation in role testing procedures
    • Use transaction SWU_OBJS to identify all business objects used in active workflows
    • Cross-reference business object authorization requirements with role assignments

  4. Workflow-Specific Configuration Check:

    • Transaction SWDD → Open the formula approval workflow
    • Check binding between workflow container and task container
    • Verify that the business object type matches the authorization object configuration
    • Ensure no custom authorization checks were added in workflow method implementation

The root cause is that role consolidation focused on transactional access but didn’t account for the multi-layered authorization requirements in workflow approval scenarios. The workflow approval logic requires both workflow execution authority AND business object modification authority, which are often split across different authorization objects in SAP PLM recipe management.

After implementing these fixes, your Recipe Approvers should regain access. Document the complete authorization object list for recipe approval workflows to prevent similar issues in future role maintenance activities.

5

Run SU53 immediately after the authorization failure while still logged in as the affected user. This will show you exactly which authorization object is missing. Most likely it’s related to C_STPO_MAR or a custom Z-object if you have formula-specific extensions. Check if the new composite role includes the approval workflow authorization objects.