IP approval workflow not triggering automatically for new patent records after import

PLM ENOVIA
, , , , , , , ,
1

We’re importing new patent records from our external IP management system into ENOVIA R2022x using XML import mappings. The import process completes successfully and the patent records are created with all the correct attributes. However, the IP approval workflow that should start automatically for new patents isn’t triggering. When we manually start the workflow on these imported records, it runs fine. The workflow has an auto-start flag configured for the Patent object type. Here’s our import mapping configuration:


<ObjectMapping type="Patent">
  <Attribute name="patentNumber" source="patent_id"/>
  <Attribute name="filingDate" source="filing_date"/>
  <Workflow autoStart="true" name="IP_Approval_Process"/>
</ObjectMapping>

We need the workflow to start automatically because we import hundreds of patents monthly and manual workflow initiation isn’t practical. Has anyone dealt with auto-start workflows not triggering for imported objects?

system 2

I’ve implemented several IP management integrations with ENOVIA and this auto-start workflow issue is a frequent challenge. The solution requires addressing three key configuration areas:

1. Import Mapping Configuration Your XML mapping is close but incomplete. The autoStart attribute in the mapping doesn’t actually trigger workflows - it’s a flag that tells the import process to respect object-level auto-start policies. You need to enhance your mapping to include post-import processing:


<ObjectMapping type="Patent">
  <Attribute name="patentNumber" source="patent_id"/>
  <Attribute name="filingDate" source="filing_date"/>
  <PostImportAction type="WorkflowStart">
    <WorkflowName>IP_Approval_Process</WorkflowName>
    <TriggerCondition>onCreate</TriggerCondition>
  </PostImportAction>
</ObjectMapping>

This explicit post-import action ensures the workflow starts after the object is fully created and all attributes are populated.

2. Workflow Auto-Start Flag Configuration The workflow definition itself needs proper auto-start configuration. In the ENOVIA workflow administration, edit your IP_Approval_Process workflow and verify these settings:

  • Auto-Start Enabled: YES
  • Trigger Event: Object Create
  • Target Types: Patent (explicitly listed)
  • Execution Context: Immediate (not deferred)
  • Required Attributes: List any attributes that must be populated before workflow can start

The key is the ‘Required Attributes’ setting. If your workflow expects certain patent attributes to be populated (like filingDate, inventorName, etc.) and they’re not available at the instant of object creation during import, the auto-start will silently fail. Review the process logs with debug logging enabled:


wt.workflow.engine.autoStartDebug=true
wt.import.workflowTrigger.logLevel=VERBOSE

The logs will show you exactly why auto-start is failing - usually it’s either missing required attributes or permission issues.

3. Process Log Review and Event Handler Verification The fact that your process logs show no workflow start attempts indicates the create event handler isn’t firing. This happens when imports use bulk loading APIs that bypass normal object lifecycle events for performance. You have two options:

Option A - Modify the import process to use standard object creation APIs:

Switch from bulk import to individual object creation, which will fire proper lifecycle events but will be slower.

Option B - Add a post-import workflow trigger script (recommended):

Create a scheduled task or post-import script that runs after each import batch:


// Pseudocode - Post-import workflow starter:
1. Query for Patent objects created in last import batch (by creation date/import flag)
2. Filter for patents without active workflows
3. For each patent:
   - Validate required attributes are populated
   - Check user has workflow start permissions
   - Start IP_Approval_Process workflow programmatically
4. Log results and any failures
// See ENOVIA Java API: WorkflowHelper.startWorkflow()

Implement this as a post-import step in your integration. It’s more reliable than depending on auto-start during bulk imports because it ensures all attributes are committed and the object is fully accessible before workflow initiation.

The combination of explicit post-import actions in your mapping, proper workflow auto-start configuration with required attributes validation, and a fallback post-import script will ensure workflows start reliably for all imported patent records.

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

3

The XML import mapping syntax looks correct, but auto-start workflows during import can be tricky. First question - is the workflow auto-start configured at the object type level in ENOVIA, or only in the import mapping? You need both. The object type definition should have a policy that triggers the workflow on creation. The import mapping just tells the import process to respect that policy.

4

I’ve seen this issue before. The problem is usually that the import process creates objects in a way that bypasses the normal object creation lifecycle events that trigger auto-start workflows. Check if your Patent object type has a lifecycle policy with a ‘Create’ event handler that starts the workflow. If the import is using direct database insertion or a different API path, it might skip those event handlers entirely. You may need to modify your import process to explicitly start workflows after object creation.

5

Good point about the lifecycle policy. I checked and the Patent type does have a Create event that should trigger the IP_Approval_Process workflow. The event handler is configured and enabled. I’m wondering if the issue is with the import process timing - maybe the workflow is trying to start before all the patent attributes are fully populated? The process logs show the patent objects being created but no entries about workflow start attempts.

6

Check your import process execution mode. If it’s running in batch mode or with transaction batching enabled, the create events might be deferred until the entire batch commits. By that time, the auto-start flag context is lost. Try running the import in single-transaction mode for testing, or add an explicit post-import step that queries for patents without active workflows and starts them. The process logs not showing workflow start attempts suggests the events aren’t firing at all during import.

7

Another possibility is that the import user account doesn’t have the necessary permissions to start workflows. Even though the objects are created successfully, workflow initiation requires specific permissions. Verify that the service account used for imports has ‘Start Workflow’ permission on the Patent type and ‘Execute’ permission on the IP_Approval_Process workflow definition. This is a common oversight in import configurations.

ctorres 8

“Tested this on ENOVIA R2022x and adding the post-import processing hook alongside correcting the autoStart attribute behavior in the XML ObjectMapping resolved our patent workflow trigger issue immediately.”