Authorization fails for custom role on workflow signoff tasks in Teamcenter 13.1

[kenji_s]

We created a custom role called ‘Technical Reviewer’ in Teamcenter 13.1 for our engineering change workflow. The role is properly defined in Access Manager with appropriate privileges, and users are successfully assigned to this role. However, when these users try to complete signoff tasks in the workflow, they receive authorization failures.

The error message is generic: ‘User does not have sufficient privileges to perform this operation.’ The same workflow works perfectly when we use standard Teamcenter roles like ‘Designer’ or ‘Engineering Manager.’ We’ve verified the custom role has read/write access to the change objects and workflow tasks.

The workflow template includes the custom role as a valid signoff participant. In Access Manager, the role shows all the necessary task-related permissions. Users can view the tasks in their inbox but cannot complete, approve, or reject them. What’s the missing link between custom role permissions and workflow template assignment that’s causing this authorization block?

The authorization failure for your custom role on workflow signoff tasks is a multi-layered permission issue. Here’s how to resolve all three critical areas:

1. Custom Role Permissions Configuration: Your Technical Reviewer role needs specific workflow-related privileges beyond basic object access. In Access Manager, navigate to the custom role definition and verify these privileges are explicitly granted:

• Workflow > Perform Signoff
• Workflow > Complete Task
• Workflow > Add Comments
• Task > Read Task Properties
• Task > Modify Task Status

Standard roles have these automatically, but custom roles start with minimal privileges. Additionally, grant these object-level privileges for the change object types used in your workflow:

• Change Item > Modify Properties (not just Read/Write)
• Change Process > Participate in Process
• Signoff > Create/Delete/Modify Signoff

The key privilege often missed is ‘Participate in Process’ - this is what allows role members to act on workflow tasks.

2. Workflow Template Assignment Correction: The workflow template needs explicit handler configuration for custom roles. Here’s what to fix:

Open your workflow template in Workflow Designer and locate the signoff task node. In the task properties:

• Go to Handlers tab
• Ensure ‘Technical Reviewer’ is added as a handler type ‘Role’
• Set the assignment rule to ‘Role-based’ not ‘Group-based’
• In the Assignment section, specify: “Assign to users who have Technical Reviewer role on the target change object”
• Enable ‘Dynamic Assignment’ if users are assigned the role during workflow execution

The critical mistake is often adding the role to the general participant pool but not to the specific task handler configuration. Each signoff task needs its handler list explicitly defined.

3. Access Manager Configuration Validation: Access Manager rules need to evaluate your custom role correctly for workflow contexts. Create or modify these rules:

Rule 1 - Grant Workflow Task Access:

• Condition: User has role ‘Technical Reviewer’ AND Task is assigned to user
• Grant: All workflow operation privileges on EPMTask
• Scope: All change-related workflows

Rule 2 - Grant Change Object Access During Workflow:

• Condition: User has role ‘Technical Reviewer’ AND Object is in active workflow
• Grant: Modify privileges on Change Item and related objects
• Scope: Change management process

Rule 3 - Grant Signoff Creation:

• Condition: User has role ‘Technical Reviewer’ AND User is task assignee
• Grant: Create/Modify/Delete on Signoff objects
• Scope: All signoff tasks

Access Manager evaluates rules in order, so ensure these custom role rules have higher priority than generic deny rules.

Verification Steps:

1. Log in as a user with Technical Reviewer role
2. Navigate to a test workflow task in your inbox
3. Right-click the task and select ‘Show Effective Access’
4. Verify all required privileges show as ‘Granted’
5. If any show ‘Denied’, trace back through Access Manager rules to find the blocking rule

Additional Configuration:

Check the workflow process template’s participant configuration file (usually XML-based). Ensure the custom role is registered:

<ValidParticipants>
  <Role name="Technical Reviewer" type="custom"/>
</ValidParticipants>

Also verify in Organization preferences that Technical Reviewer is enabled for workflow participation:

• Go to Organization > Preferences > Workflow
• Add Technical Reviewer to ‘Allowed Workflow Roles’ list
• Save and propagate to child organizations

Testing Protocol:

After making these changes:

1. Clear the Access Manager cache: Utilities > Clear Cache > Access Manager
2. Restart the workflow service
3. Create a new workflow instance (don’t test on existing ones)
4. Assign a user with Technical Reviewer role to the signoff task
5. Verify the user can complete the signoff

If authorization still fails, enable detailed Access Manager logging and review the evaluation trace to see exactly which privilege is being denied and why. This will pinpoint any remaining configuration gaps.

---

This draft is based on general Teamcenter knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

[krish_verma]

Check if your custom role has the specific workflow action privileges. It’s not enough to have read/write on the objects - you need explicit privileges for workflow operations like ‘Perform Signoff’ and ‘Complete Task’. These are separate privileges in Access Manager under the Workflow category. Standard roles have these by default, but custom roles require manual assignment.

[marcussiemens]

I suspect the issue is in your workflow template configuration. When you add a custom role as a signoff participant, you need to specify it in the handler assignment, not just in the general participant list. Open your workflow template in Workflow Designer, go to the signoff task properties, and verify that ‘Technical Reviewer’ is explicitly listed in the Task Assignment section with the correct assignment type (role-based).

[plm_esh]

This could also be an Access Manager rule evaluation issue. Custom roles sometimes don’t inherit the necessary access rules automatically. Check your Access Manager rules for the change object type - there should be rules that grant workflow task privileges based on role membership. You might need to create a new rule specifically for your Technical Reviewer role that grants workflow operation privileges on change objects when the user is assigned to a signoff task.

“Confirmed this resolves the signoff failure — explicitly granting ‘Workflow > Perform Signoff’ and ‘Workflow > Complete Task’ privileges in Access Manager fixed our Technical Reviewer role in TC 13.1.”

[migueld]

Don’t overlook the Organization context. Custom roles often require proper Organization setup to work with workflows. Verify that users with the Technical Reviewer role are in the correct Organization, Group, and Role combination. The workflow might be checking for organizational hierarchy permissions in addition to role-based permissions. Try assigning the role within the same Organization where the change object was created.

[ingrid_solution]

Have you checked the signoff task’s ACL directly? Sometimes workflow tasks have their own access control lists that override role-based permissions. Use the ‘Show ACL’ function on a specific task instance to see what permissions are actually being evaluated. If the ACL doesn’t include your custom role, that’s your problem right there.

[erp_arch]

Another angle - profile templates. If your users are being assigned the custom role through profile templates, make sure the profile includes all the necessary supporting roles and privileges. Sometimes a custom role needs to be paired with certain system roles to function properly in workflows. Check if Technical Reviewer needs to also have something like Workflow Participant or Task Assignee as secondary roles.