ECO API callback not triggered when status changes from 'Submitted' to 'In Review'

PLM Oracle Agile PLM
, , , , , , ,
1

We’ve configured webhook callbacks for ECO status changes in Agile 9.3.4 to trigger downstream system updates. The webhook fires correctly when ECOs move from ‘In Review’ to ‘Approved’, but completely fails to trigger when transitioning from ‘Submitted’ to ‘In Review’. Our downstream systems are missing critical notifications for this workflow stage. The webhook configuration looks identical for both transitions in our setup. Has anyone experienced selective webhook event mapping issues with ECO workflow? Are there specific status transition filters or workflow configuration requirements we’re missing for the initial review stage?

2

Your webhook issue relates to how Agile maps workflow events to API callbacks and how status transitions are filtered in the event system. Let me address the three key areas:

Webhook Event Mapping: Agile’s webhook system categorizes ECO events into distinct types based on the workflow action that triggered them, not just the status change itself. The transition to ‘Approved’ generates a ‘change.approval’ event because it involves approval workflow logic. However, ‘Submitted’ to ‘In Review’ might be classified differently depending on your workflow configuration:

  • If it’s a manual reviewer assignment, it generates ‘assignment.reviewer’ event
  • If it’s an automatic transition, it generates ‘change.status.auto’ event
  • If it requires acknowledgment, it generates ‘acknowledgment.pending’ event

Your webhook subscription to ‘change.status’ events only captures explicit user-initiated status changes, not system-automated or workflow-specific transitions. You need to subscribe to multiple event types to capture the complete ECO lifecycle.

Status Transition Filters: Webhook configurations in Agile include status-based filters that determine which transitions trigger callbacks. Check your webhook setup for status filter configuration. The filter might be set to trigger only on specific destination statuses. For example, if your filter is configured as ‘status IN (Approved, Rejected)’, it won’t fire for transitions to ‘In Review’.

Additionally, some workflow transitions have preconditions that must be met before the status change is committed. If the webhook is configured to fire on committed status changes, it won’t trigger for transitions that are pending precondition validation. Review your ECO workflow in Java Client to see if ‘Submitted’ to ‘In Review’ has preconditions like mandatory field validation or reviewer assignment.

Workflow Configuration: The root cause is likely in your ECO workflow definition. Navigate to Admin > Workflow > ECO workflow and examine the transition from ‘Submitted’ to ‘In Review’. Look for:

  1. Transition type (manual vs automatic)
  2. Pre-transition actions or scripts
  3. Event generation settings for this specific transition
  4. Whether the transition requires user interaction (assignment, acknowledgment)

If the transition is configured as automatic based on criteria, you’ll need to add a custom workflow script that explicitly triggers your webhook. Use the Agile SDK’s event API to fire a custom event that your webhook can subscribe to.

Solution Steps:

  1. Enable webhook debug logging: Set log level to DEBUG for com.agile.api.webhook in log4j configuration
  2. Trigger the ‘Submitted’ to ‘In Review’ transition and examine server logs to see what event (if any) is generated
  3. If no event is generated, the transition is configured as silent - add a workflow script to fire a custom event
  4. If an event is generated but your webhook isn’t receiving it, update your webhook subscription to include that event type
  5. Review status filters in webhook configuration and ensure ‘In Review’ status is included

For immediate resolution, subscribe your webhook to these event types: ‘change.status’, ‘change.status.auto’, ‘assignment.reviewer’, and ‘workflow.transition.eco’. This broader subscription will capture the ‘Submitted’ to ‘In Review’ transition regardless of how it’s configured in the workflow.

3

Check your workflow definition for the ECO class. Some status transitions are configured as automatic transitions that don’t trigger standard event handlers. If ‘Submitted’ to ‘In Review’ is set up as an auto-promotion based on criteria, it might bypass the normal status change events that webhooks listen to. You’d need to add an explicit workflow script to fire the webhook in that case.

4

The event types are defined in the workflow configuration, not in the API documentation unfortunately. Each status transition can be mapped to different event types based on how the workflow is designed. Your best bet is to enable webhook debug logging on the Agile server to see exactly what events are being generated for each transition. Check the server logs in the agile/log directory for webhook event details.

5

I’ve seen this before with webhook event subscriptions. The API webhook configuration has granular event type filters. You might have subscribed to ‘approval’ events but not ‘status change’ events. The transition to ‘Approved’ triggers an approval event, while ‘Submitted’ to ‘In Review’ is just a status change. Check your webhook subscription settings and make sure you’re subscribed to both event types.

6

Sam, that’s a good point. I looked at our webhook subscription and we’re subscribed to ‘change.status’ events for the ECO class. But I’m seeing in the event log that status changes to ‘Approved’ show up as ‘change.approval’ events, not ‘change.status’. So maybe ‘Submitted’ to ‘In Review’ is using a different event type altogether? Where can I find the complete list of event types that Agile generates for ECO workflows?