State transition fails in lifecycle management due to missing policy assignment via REST API

PLM ENOVIA
, , , , , , , ,
1

I’m creating Part objects via REST API in ENOVIA R2022x, but when attempting to promote them through lifecycle states, I get a ‘No policy assigned’ error. The API object creation completes successfully, but the lifecycle state transition fails.

Error from the API response:


POST /enovia/resources/v1/modeler/parts/promote
Response: 400 Bad Request
"error": "No policy assigned to object"
"details": "Lifecycle promotion requires valid policy"

My part creation payload includes basic attributes but I’m not explicitly setting a policy assignment during object creation. I assumed ENOVIA would apply a default policy, but apparently that’s not happening. How do I properly assign a policy through the REST API so that lifecycle state transitions work? The workflow is completely blocked without proper policy assignment.

system 2

Your issue stems from incomplete API object creation that doesn’t establish the policy context required for lifecycle state transitions. Here’s the comprehensive solution addressing all three focus areas:

Policy Assignment: When creating Parts via REST API, you must explicitly assign a policy. Modify your POST request to include policy information:

POST /enovia/resources/v1/modeler/parts
{
  "type": "Part",
  "name": "PART-12345",
  "policy": "EC Part",
  "current": "Preliminary"
}

The ‘policy’ field specifies which lifecycle policy governs the object, and ‘current’ sets the initial state. Without both, ENOVIA creates an unmanaged object that cannot participate in lifecycle workflows.

API Object Creation: For robust API object creation with proper policy assignment, implement this pattern:

  1. Query available policies: Before creating objects, retrieve valid policies for the Part type:
GET /enovia/resources/v1/modeler/types/Part/policies

This returns policies accessible to your API user. Select an appropriate policy based on your part classification (prototype, production, etc.).

  1. Verify policy states: Each policy defines specific states. Query the policy details:
GET /enovia/resources/v1/modeler/policies/EC%20Part

The response shows available states and transition rules. Always set ‘current’ to the policy’s initial state (typically the first state in the lifecycle).

  1. Complete creation payload: Include all required fields for policy-managed objects:
{
  "type": "Part",
  "name": "PART-12345",
  "revision": "A",
  "policy": "EC Part",
  "current": "Preliminary",
  "vault": "Engineering",
  "owner": "api_service_account"
}

Vault and owner are critical - some policies restrict object creation to specific vaults or require owner assignment for proper access control during lifecycle transitions.

Lifecycle State Transition: Once objects are created with proper policy assignment, state transitions work correctly:

  1. Promotion request structure:
POST /enovia/resources/v1/modeler/parts/{objectId}/promote
{
  "action": "Promote",
  "comments": "Ready for review"
}
  1. Validate transition eligibility: Before promoting, check if the object can transition:
GET /enovia/resources/v1/modeler/parts/{objectId}/nextStates

This returns valid next states based on the current state and policy rules. Only attempt transitions to states listed in this response.

  1. Handle signature requirements: Some state transitions require signatures or approvals. If your promotion fails with signature-required errors, you’ll need to complete approval workflows first:
POST /enovia/resources/v1/modeler/parts/{objectId}/signatures
{
  "signatureType": "Approve",
  "user": "approver_username"
}
  1. Error handling: Implement proper error handling for lifecycle operations:
try {
  promotePart(partId);
} catch (PolicyException e) {
  // Check if policy is assigned
  // Verify current state is valid
  // Ensure user has promotion rights
}

Best Practices for API-driven Lifecycle Management:

  • Always retrieve and validate policy information before object creation
  • Cache policy definitions to avoid repeated API calls
  • Implement retry logic for transient failures during state transitions
  • Log all lifecycle operations for audit and troubleshooting
  • Use batch operations for multiple object promotions to improve performance

After implementing these changes, your API-created Parts will have proper policy assignments and lifecycle state transitions will execute successfully. The key is ensuring complete object initialization during creation rather than attempting to add policy context later.

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

You need to include the policy in your POST request when creating the Part. The REST API doesn’t auto-assign policies like the UI might. Add a ‘policy’ field to your JSON payload with the policy name, typically something like ‘EC Part’ or ‘Development Part’ depending on your ENOVIA configuration. Without explicit policy assignment, the object is created in an unmanaged state.

4

Check what policies are available for the Part type in your environment. Use the GET endpoint /enovia/resources/v1/modeler/types/Part/policies to retrieve valid policies. Then reference the exact policy name in your creation request. Policy names are case-sensitive in the API, which catches people frequently.

5

Beyond just setting the policy, make sure your API user has the right access to assign that policy. Some policies have restricted assignment permissions. If the service account creating parts doesn’t have policy assignment rights, the creation might succeed but leave the object in an invalid state for lifecycle operations. Check role assignments for your API user.

patrick_spencer 6

Confirmed this resolves the state transition error — explicitly including the "policy": "EC Part" field in the REST API POST payload correctly initialized the ENOVIA lifecycle context.

7

I’ve seen this exact issue. The problem is that policy assignment through REST API requires both the policy name AND the initial state. If you only specify the policy without setting the current state, ENOVIA can’t properly initialize the lifecycle. Your payload should include both ‘policy’ and ‘current’ fields to place the object in the correct starting state of that policy’s lifecycle.

8

Don’t forget vault assignment. Some policies require objects to be in specific vaults. If your API creation doesn’t specify a vault, or specifies an incompatible vault for the chosen policy, you’ll get policy-related errors even if the policy name is correct.

9

Test your policy assignment with a simple GET request first. Retrieve an existing Part that has proper lifecycle setup and examine its JSON structure. This will show you the exact format ENOVIA expects for policy and state fields in your POST requests.