Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Field MKT campaign insert duplicate rows in PR_Data_IH_Fact



User created a field marketing campaign, with offer flow having an update shape. After campaign is executed, two rows gets inserted in PR_DATA_IH_FACT and MKT_Communication_history for each offer generated and sent to customers(using email).

Say for example, Campaign generated two offers for two customer via email channel. For this four rows gets inserted, two for each single offer sent.

  • One row has null values for pychannel and XYZ_NBR (customer property)
  • One row has proper values for pychannel and XYZ_NBR (customer property)

When the Update shape is removed in the offer flow, instead of duplicate rows, only two rows for two offers sent but the row has null values for pychannel and XYZ_NBR.

Error Messages

Not Applicable

Steps to Reproduce

Create a Field marketing campaign and run the same.

Root Cause

An issue in the custom application code or rules

User was enquiring whether there is any possibility of avoiding two entrees created in the
Interaction History (IH) fact table.


Here’s the explanation for the reported behavior:

All campaigns (Field Marketing, Outbound or Multi-channel) will create an entry in IH to represent that offers are being initiated for a customer. This entry will have an outcome of 'Pending'. 

The channel for this pending record will not be set unless the strategy sets it in advance (only available in multi-channel campaigns).  Subsequent shapes in an offer flow can explicitly add IH entries for for different outcomes and channels.  As such every campaign will have a minimum of one entry in IH whose outcome will be Pending.

There is functional meaning behind a pending record and other records  which means that an interaction is pending, and the actual interaction will be recorded when it happens. 

IH is data store that is optimized for fast inserts and fast reads and as such it is built with insert only mechanics.

The combination of these two elements mean there will be two records for current scenario.



Published July 23, 2018 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us