Skip to main content
Question

Business Rule Running Twice and creating duplicate records

  • July 23, 2026
  • 1 reply
  • 4 views
D
Sidekick (Partner)
Forum|alt.badge.img+7

We have a business rule that is running twice resulting in duplicate records in the task table. Do you know what could possibly be causing this?  and there is no biplicate brs configured 

please any one suggest why  duplicate records are creating ?  

Execution point: After commit update. 

xml message xml:

<perform_batch>
<update_task>
<task>
<task_id />
<access_group>NO_CMR_STC_HQ_EMC_RECEIVE_SHIP</access_group>
<description>Faulty Spare Repair Return EMC Receiving shipping task</description>
<parent_task_id>@task_id</parent_task_id>
<place_id_cust>@place_id_cust</place_id_cust>
<plan_start_dttm>@modified_dttm</plan_start_dttm>
<request_id>@request_id</request_id>
<task_status>OPEN</task_status>
<task_type>FAULTY_SP_REPAIR_N_RETURN_EMC_RS</task_type>
<insert is_initialized="False" />
</task>
</update_task>
</perform_batch>

 

XML validation:

<hierarchy_select>
<primary_table>task</primary_table>
<attrs>
<attr>task.task_id</attr>
</attrs>
<from>
<table>task</table>
</from>
<where>
<data_constraint>
<constraint>
<left_operand>task.request_id</left_operand>
<operator>eq</operator>
<right_operand>@request_id</right_operand>
</constraint>
<constraint>
<left_operand>task.task_type</left_operand>
<operator>eq</operator>
<right_operand>FAULTY_SP_REPAIR_N_RETURN_EMC_RS</right_operand>
</constraint>
</data_constraint>
</where>
</hierarchy_select>

1 reply

M
Hero (Employee)
Forum|alt.badge.img+10
  • Morris
  • Hero (Employee)
  • July 23, 2026

Hi ​@Durga ,

 

Have you confirmed via the Business Rule Watch or server logs that the BR is actually executing twice?

Also, are you certain both tasks are being created by this same BR? One way to verify this would be to populate an unused User Defined field with the BR name or ID when the task is created. That would quickly confirm the source of each record.

Since the rule is already comparing the old and new values of task_status, I would not immediately suspect the trigger condition itself.

Instead, I would focus on:

  • Is the BR actually executing twice?
  • Is another BR, workflow, integration, or process creating the second task?
  • How is the Validation XML configured within the rule?
  • Is the rule running synchronously or asynchronously?
  • Is the validation being used to prevent execution when a matching task already exists?

I would start with the BR Watch/server logs and the creation timestamps of the duplicate tasks. That should quickly tell us whether we're dealing with two executions of the same BR, another process creating the second task, or a validation/configuration issue.

Thanks,

Morris

 

Terms & ConditionsAccessibility statement