Change request workflow stuck on custom state after data model update

Our ECO workflow is getting stuck at a custom state we added called ‘Technical_Review’ after we updated our data model last week. The workflow was working perfectly before we added new custom properties to the ECO ItemType. Now when ECOs reach Technical_Review state, they won’t transition to the next state (Engineering_Approval) even when users click the workflow action button.

We modified the Life Cycle Map to include this custom state between the standard Review and Approved states. The workflow transition mapping looks correct in the Workflow Map editor - the path from Technical_Review to Engineering_Approval is clearly defined with appropriate activities. No error messages appear, the workflow action just doesn’t execute. The ECO remains in Technical_Review indefinitely.

This is causing major delays in our change approval process. Users with proper permissions can see the workflow actions, but clicking them does nothing. Has anyone experienced workflow state transitions failing after data model changes?

I checked the permissions and they look correct - the same identities have access to Technical_Review as the other states. The workflow transition arrow exists in the map pointing from Technical_Review to Engineering_Approval. Could the issue be related to the new custom properties we added? They’re all optional fields so I wouldn’t expect them to block workflow progression.

I’ve dealt with this exact scenario. The workflow transition mapping needs to be synchronized with the Life Cycle Map after you make changes. Go to the Workflow Map and check if the transition from Technical_Review has the correct target state configured. Sometimes when you insert a new state into an existing lifecycle, the workflow paths don’t automatically update. You may need to delete and recreate the transition arrow in the Workflow Map editor.

The data model update might have invalidated cached workflow definitions. After making changes to ItemType properties, you should rebuild the workflow cache. Go to Administration > Workflow Maps, select your ECO workflow, and use the ‘Refresh’ action. This forces Aras to regenerate the workflow execution paths with the updated data model. Also verify that your Life Cycle Map version matches the Workflow Map version - they need to be synchronized.

Another possibility - check if there are any onBeforePromote or onAfterPromote server events defined on your ECO ItemType. When you modified the data model, existing event handlers might be throwing exceptions that prevent state transitions. These events execute during workflow progression and can silently block transitions if they fail. Review the server event methods and add error logging to identify any issues.

Check the Workflow Process activities associated with the transition. Sometimes workflow activities have validation logic that checks property values before allowing state changes. If your new custom properties are being referenced in an activity script but aren’t properly initialized, the workflow can silently fail. Look at the Workflow Process definition and examine any server methods or validation activities that execute during the Technical_Review to Engineering_Approval transition. Also check the Aras event logs for any hidden errors.

Based on the symptoms you’re describing, this is a three-part configuration issue that commonly occurs after data model updates:

1. Life Cycle Map Configuration: When you inserted the Technical_Review state into your existing lifecycle, the state sequence needs proper configuration. Open your Life Cycle Map and verify:

  • The Technical_Review state has a sequence number between Review and Engineering_Approval states
  • The ‘can_delegate’ and ‘can_refuse’ properties are set appropriately
  • Most importantly, check if the Technical_Review state has the ‘is_release_state’ property set incorrectly - if this is set to ‘1’ when it shouldn’t be, workflow transitions can hang

2. Workflow Transition Mapping: The workflow path configuration needs explicit validation:

  • Open the Workflow Map editor and select the transition arrow from Technical_Review to Engineering_Approval
  • Verify the transition has activities assigned (even if just an auto-activity)
  • Check the transition’s ‘Segments’ property - it should have proper path configuration
  • Ensure the ‘role’ property on the transition matches an identity that has permissions on both states
  • Critical: Verify that the workflow transition’s ‘source’ and ‘target’ properties explicitly reference the correct state IDs from your Life Cycle Map

3. Permissions on Custom State: This is the most commonly overlooked aspect. The Technical_Review state needs comprehensive permission configuration:

  • Open the Life Cycle Map, select Technical_Review state, go to Access tab
  • Grant the following permissions to relevant identities:
    • ‘can_read’ - required for visibility
    • ‘can_update’ - required for workflow action execution
    • ‘can_promote’ - CRITICAL - without this, transitions won’t execute
  • Compare the permission set on Technical_Review with your Review state - they should be nearly identical
  • Don’t forget to grant permissions to the Workflow Process identity itself if your workflow uses automated activities

Why Your Data Model Update Caused This: When you added custom properties to the ECO ItemType, Aras likely regenerated the ItemType cache. If the Life Cycle Map wasn’t properly versioned or if workflow permissions weren’t explicitly saved, the cache rebuild can lose permission associations on custom states. This is a known issue in Aras 13.0 when modifying ItemTypes that have custom lifecycle states.

Resolution Steps:

  1. Export your current Life Cycle Map and Workflow Map as backup
  2. Open Life Cycle Map > Technical_Review state > Access tab
  3. Add ‘can_promote’ permission to all identities that should be able to transition ECOs
  4. Save the Life Cycle Map
  5. Open Workflow Map > Right-click > Refresh/Rebuild
  6. Test with a test ECO item - create one, manually set it to Technical_Review state, then try the workflow action

Verification Query: Run this to check if permissions exist:


SELECT * FROM [PERMISSION] WHERE source_id IN
(SELECT id FROM [LIFE_CYCLE_STATE] WHERE name = 'Technical_Review')

If this returns empty or missing ‘can_promote’ entries, that’s your issue. The workflow engine checks can_promote permission before executing any state transition, and without it, the action silently fails with no error message - exactly what you’re experiencing.

This sounds like a permissions issue on the custom state. When you add a new state to the Life Cycle Map, you need to explicitly grant permissions for that state to the appropriate identities. Check the Access tab on your Technical_Review state - make sure the same identities that have permissions on other states also have permissions on Technical_Review. Without proper read/write permissions, workflow transitions won’t execute even if the mapping is correct.