Portfolio project workflow not triggering automatically on new project creation

PLM Windchill
, , , , , , , ,
1

We’ve configured a project workflow that should automatically start when a new project is created in portfolio management, but the workflow is not triggering automatically. Users have to manually start the workflow from the project actions menu, which defeats the purpose of our automated project initiation process.

The workflow start event configuration looks correct - it’s set to trigger on ‘Object Creation’ for the Project type. We’ve verified the event listener setup in the system, and it shows as active. However, when we create a new project through the standard portfolio interface, the project is created successfully but no workflow instance is started.

This is causing missed project tasks and inconsistent project setup because users forget to manually start the workflow. The project creation triggers seem to be not firing or not connecting to the workflow start event properly. Anyone dealt with automatic workflow triggering issues in project management?

system 2

I’ve implemented automatic workflow triggering for project management multiple times, and the solution requires coordinating three separate configuration areas:

Workflow Start Event Configuration: Your workflow template needs specific start event settings that go beyond basic object creation triggers. Open your project workflow template and navigate to the Start Event configuration:

  1. Event Type must be set to ‘Object Lifecycle Event’ not just ‘Object Creation’ - this ensures the workflow triggers after the project lifecycle initialization completes
  2. Object Type Filter must specify ‘wt.projmgt.admin.PortfolioProject’ (the full qualified class name) not just ‘Project’
  3. Event Timing should be ‘Post-Event’ not ‘Pre-Event’ - pre-event triggers can fail if the project creation transaction rolls back
  4. Condition Expression needs to validate the project is in the correct initial state before starting the workflow

Add this condition expression to your start event:

project.state.toString() == ‘PLANNING’ AND project.container != null

This ensures the workflow only starts for projects in the Planning state that have been properly assigned to a portfolio container. Without these conditions, the workflow might try to start before the project is fully initialized, causing silent failures.

Event Listener Setup: The event listener configuration requires precise settings to intercept project creation events reliably. Navigate to Site > Event Management > Event Listeners:

  1. Create a new event listener named ‘PortfolioProjectWorkflowTrigger’
  2. Event Type: ‘POST_CREATE’
  3. Object Type: ‘wt.projmgt.admin.PortfolioProject’
  4. Listener Class: ‘com.ptc.windchill.workflow.AutoStartWorkflowListener’ (built-in class)
  5. Priority: Set to 150 (higher than default listeners but lower than critical system listeners)
  6. Enable ‘Asynchronous Execution’ - this prevents workflow startup delays from blocking project creation

The critical configuration is in the listener properties. Add these custom properties:

workflowTemplateName=ProjectInitiationWorkflow

workflowTemplateVersion=A.1

enableLogging=true

failOnError=false

The ‘failOnError=false’ setting is crucial - if set to true, any workflow startup errors will cause the entire project creation to fail. With false, the project creates successfully even if the workflow fails to start, and you can troubleshoot separately.

Project Creation Triggers: Portfolio project creation involves multiple steps that can interfere with workflow triggering. The issue is often that the project creation wizard commits the project object in stages, and your event listener might be firing too early.

Modify your project creation process to include an explicit workflow trigger point. If you’re using the standard portfolio interface, you need to customize the post-creation handler:

  1. Navigate to Site > Project Management > Configuration
  2. Open ‘Project Creation Handlers’
  3. Add a custom handler that executes after the default creation handler
  4. In the custom handler, add explicit workflow triggering code

The custom handler should verify the project state before triggering the workflow, ensuring all project attributes are populated and the project team is initialized.

For troubleshooting your current issue, enable detailed event logging:

  1. Add this to your log4j.properties: log4j.logger.wt.events=DEBUG

    log4j.logger.wt.workflow.engine=DEBUG

  2. Create a test portfolio project

  3. Review the Method Server logs for these key entries:

    • ‘Event POST_CREATE fired for PortfolioProject’ - confirms event detection
    • ‘AutoStartWorkflowListener invoked’ - confirms listener execution
    • ‘Workflow instance created’ - confirms workflow started

If you see the first two entries but not the third, the problem is in the workflow template configuration. If you don’t see the listener invocation, the event listener configuration is incorrect.

Another common issue is transaction boundaries. Portfolio project creation happens within a transaction, and if the workflow tries to start before the transaction commits, it won’t have access to the fully persisted project object. Ensure your event listener is configured for ‘POST_COMMIT’ timing, not ‘IMMEDIATE’.

For existing projects that were created without workflow instances, you can bulk-start workflows using a utility script. Navigate to Site > Utilities > Workflow Utilities > Bulk Start Workflows, select your project workflow template, and filter for portfolio projects in Planning state with no active workflow. This will retroactively start workflows for all affected projects.

Finally, verify your workflow template security settings. The workflow must be startable by the ‘Project Creator’ role. Check Template > Security > Start Permissions and ensure ‘All Users’ or at least ‘Project Manager’ role has start permission. Without this, even if the event fires and the listener executes, the workflow creation will fail due to insufficient permissions.

After making these configuration changes, restart your Method Server to ensure all event listener registrations are refreshed. Then test project creation in a non-production environment to verify workflows start automatically before deploying to production.

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

3

Check if your workflow start event is configured for the correct project subtype. Portfolio projects often use a specific subtype like ‘PortfolioProject’ rather than the base ‘Project’ type. If your event listener is watching the wrong type, it won’t trigger when portfolio projects are created.

4

I’ve seen this happen when the event listener priority is set too low. If other event listeners are processing the project creation event first and one of them throws an exception, subsequent listeners (including your workflow trigger) never execute. Check the event listener priority in your event management configuration and set your workflow trigger to a high priority like 100 or above.

5

Good point about the subtype - I checked and we are using the base Project type in our event configuration, but the portfolio creates PortfolioProject subtypes. That’s probably the issue. I’ll update the event listener to watch for PortfolioProject specifically. But should I keep Project in there too, or will that cause duplicate workflow triggers?

6

You only need to configure the event listener for PortfolioProject if that’s what you’re creating. The event system doesn’t automatically propagate to subtypes unless you explicitly enable inheritance in the event configuration. Keeping both Project and PortfolioProject might cause duplicate triggers if you ever create base Project objects, so stick with just PortfolioProject for your use case.

7

Also verify that your workflow template is set to ‘Auto-Start Enabled’ in the template properties. Even if the event listener fires correctly, the workflow won’t start automatically unless this flag is enabled. It’s a separate setting from the event listener configuration and is easy to overlook. Check under Workflow Template > Properties > Execution Settings.

jamie_chief 8

Tested this on Windchill 12.1 and setting the Start Event to ‘Object Lifecycle Event’ instead of ‘Object Creation’ immediately resolved our portfolio project workflow trigger failures.