ECN workflow routing fails when custom role mapping is used for cross-site approvals

We’re experiencing ECN workflow routing failures after implementing custom role mapping for cross-site approvals. Our setup uses a PX script to dynamically assign approvers based on the affected item’s site and category, but the workflow blocks at the approval step with error “Role assignment failed - no valid user found”.

The custom role mapping was configured in Admin Console to support our multi-site operations where different engineering managers need to approve changes based on item location. The PX script checks the item’s site attribute and maps it to the appropriate role:

IRole targetRole = RoleHelper.getRole("Site_" + itemSite);
workflow.addApprover(targetRole);

The workflow completes successfully when we use standard roles, but fails with our custom site-specific roles. User-role assignments are verified in Admin Console and users can log in without issues. Has anyone implemented similar cross-site role mapping for ECN workflows?

Another thing to check is whether users assigned to these custom roles have the necessary privileges. Even if the role exists and is properly mapped, the workflow will fail if the role members don’t have ECN approval privileges. Go to Admin Console → User Management → Roles, select your custom role, and verify that “Approve ECN” privilege is enabled. Also check if there are any site-based privilege restrictions that might be interfering with cross-site approvals in your implementation.

That’s likely your issue. RoleHelper.getRole() expects the internal role name, not the display name. Custom roles created through Admin Console often have different internal identifiers. Try using the Role API to query by attributes instead. Also, for cross-site scenarios, make sure your PX script handles cases where a site might not have a corresponding role defined - add null checks and fallback logic.

Here’s the complete solution addressing all aspects of your custom role mapping issue:

1. PX Script Role Resolution: The primary issue is how you’re retrieving the custom role. RoleHelper.getRole() works with role API names, not display names. Update your script:

IRole targetRole = (IRole) RoleHelper.service.getObject(
    RoleConstants.CLASS_ROLE_TYPE,
    "Site_" + itemSite + "_Approver"
);
if (targetRole == null) {
    // Fallback to default approval role
    targetRole = RoleHelper.getRole("Engineering_Manager");
}
workflow.addApprover(targetRole);

2. User-Role Configuration in Admin Console: For cross-site user management, ensure each custom role has:

  • Base workflow privileges (Approve ECN, View Workflow)
  • Site-specific users explicitly assigned as members
  • Role API name matching your PX script pattern (Site_[SiteName]_Approver)

Go to Admin Console → User Management → Roles → [Your Custom Role] and verify the API Name field matches what your script expects.

3. Workflow Template Configuration: In the ECN workflow template, the approval step must reference a role variable that can accept multiple role types:

  • Don’t hardcode specific roles in the workflow step
  • Use a role variable (e.g., $DynamicApprover) that your PX script populates
  • Set the step to “Allow Dynamic Role Assignment”

4. Cross-Site User Management: Implement a two-tier role structure:

  • Base role: “ECN_Approver” (grants workflow access to all sites)
  • Site roles: “Site_US_Approver”, “Site_EU_Approver” (determines routing)

All approvers should be members of both their site-specific role AND the base ECN_Approver role. This ensures the workflow engine recognizes them as valid approvers while your PX script handles site-specific routing.

5. Validation Steps:

  • Test role retrieval in PX debugger before deploying
  • Verify workflow cache refresh after any role changes
  • Check application server logs for “Role not found” errors during workflow execution
  • Ensure site attribute on items is populated and matches role naming convention

This approach has worked reliably for multi-site ECN approvals across several 9.3.x implementations. The key is proper role API naming and the two-tier role structure for cross-site scenarios.

Thanks for the suggestions. I verified the workflow template does include the custom roles, and privileges are correctly set. The cache refresh didn’t resolve it either. I’m wondering if the issue is in how the PX script retrieves the role - maybe RoleHelper.getRole() doesn’t work with dynamically named roles?

We had a similar setup and found that the user-role configuration needs special attention for cross-site workflows. Each site’s users must be explicitly added to their site-specific roles, but also need membership in a base approval role for the workflow engine to recognize them. It’s a two-tier approach - the base role grants workflow access, the site role determines routing.