Duplicate planning demand records created due to race condition when multiple transactions occur in quick succession on dmn_demand table (Issue across planning and execution items) - Known Error

Duplicate planning demand records created due to race condition when multiple transactions occur in quick succession on dmn_demand table (Issue across planning and execution items) Description Duplicate planning demand records are created for a single demand when multiple transactions occur in quick succession on the same dmn_demand record.

When an insert followed immediately by an update (or multiple rapid updates) is performed, the system triggers multiple subflows concurrently. This results in more than one planning demand record being created for the same source demand.

This behavior leads to duplicate records appearing in the Planning Workspace and may also result in inconsistencies between the generated records (for example, missing or incomplete data in one of the duplicates).

Refer to the attached evidence showing duplicate planning demand records and corresponding execution flow behavior.

Steps to Reproduce

1.Create a demand (dmn_demand) via Service Portal or automation 2.Immediately perform an update on the same demand (e.g., change state to Screening) 3.Ensure both transactions occur in very short time interval (milliseconds, typically via flow/automation) 4.Observe execution of subflows tied to demand creation/update 5.Navigate to Planning Workspace 6.Verify that multiple planning demand records are created for the same demand

Note: Reproduction is timing-dependent and may not consistently occur via manual UI actions Issue is more likely to reproduce when automation performs consecutive transactions quickly

Workaround Workaround 1 — Run the Execution-to-Alignment Subflow Synchronously on Insert Description The duplicate planning item(sn_align_core_demand) creation occurs because the Execution-to-Alignment subflow is started asynchronously. When a source record is inserted and then updated almost immediately, multiple transactions can invoke the subflow concurrently before either execution completes. As a result, each execution may create a planning item for the same source record.

To prevent this race condition, configure the insert transaction to invoke the subflow synchronously. This ensures that the initial transaction completes the planning item creation before any subsequent update transaction can trigger another execution.

For out-of-box Execution-to-Alignment integrations, the subflow execution is initiated from the script include:

sn_align_snow_int.APWInternalIntegrationUtils

Function:

startSubFlowForExecutionToAlignment()

The synchronous execution change should be implemented in the logic that invokes this function for record insert operations.

Update set : sync flow update set

Steps Review the Execution-to-Alignment integration logic that triggers planning item creation. In the script include sn_align_snow_int.APWInternalIntegrationUtils , identify the invocation of startSubFlowForExecutionToAlignment() . Modify the insert path so that the subflow executes synchronously (waits for completion) instead of asynchronously. Verify that the insert transaction completes planning item creation before any subsequent updates are processed. Test by creating a source record and immediately updating it to confirm that only one planning item is created. Additional Configuration Support for the following out-of-box source tables is already provided through Execution-to-Alignment integrations:

pm_project rm_epic pm_project_task dmn_demand im_idea_core sn_safe_epic If custom source tables are integrated with Portfolio planning Workspace, add the required mappings in the executionToAlignmentMap object within the APWInternalIntegrationUtils script include.

Trade-off / Side Effect Because planning item creation now occurs within the same transaction as the source record insert, the insert operation will take longer to complete. Users or integrations creating records may notice a slight increase in transaction duration.

Risk Low. This workaround does not affect existing data or history and addresses the race condition at its source.

Note: This duplicate record issue is not limited to Demand ( dmn_demand ) records. It can occur for any table integrated through the Execution-to-Alignment framework when insert and update transactions execute in rapid succession. The same workaround approach applies to all Execution-to-Alignment integrations.

Workaround 2 — Scheduled Cleanup of Duplicate Planning Items Description Run a scheduled job at a chosen interval to detect and delete duplicate planning item (sn_align_core_demand) records while retaining a single record for each source record. This serves as a mitigation approach and can be used independently or together with Workaround.

Update set : scheduled job update set

Steps

Change the application scope to the scope in which the table exists. Click on insert and stay in that scope Make the scheduled job active Choose the interval to run this job. E.g. 1hr. Duplicate planning item creation can occur for any Execution-to-Alignment integration table. The scheduled cleanup approach remains the same regardless of the source table, with only minor modifications required for table names and relationship fields used by the cleanup job.

Risk

Medium: This workaround permits duplicate records to be created and removes them later through scheduled cleanup. This is a destructive approach because it deletes records after creation. A better solution is to prevent duplicate records from being created in the first place, avoiding the need for post-creation cleanup (Workaround 1).