Skip navigation

Dev team plan to fix the Excel issue in 18B. So exporting to Excel issue should be fixed after this release.


Now we are in 18A and 18B is scheduled on Fri May 18, 2018. Please kindly refer to Oracle Eloqua Release Center ( for more details.

With GDPR fast approaching, many customers will be wanting to tidy up orphaned CDO records in order to be as compliant as possible.

This guide aims to demonstrate how Oracle Eloqua can accomplish this for you.

To avoid the potential deletion of incorrect data, a backup of your CDO is recommended before any records are actually deleted.


To do this you will need 5 assets.

  • A program builder
  • A program canvas
  • An update rule
  • A shared Filter
  • your chosen CDO*

* this solution works 'per CDO' so if you have 10 CDO's you'll need 10 of the above (with the exception of the update rule & the shared filter).


  Here is an overview of the solution:


What this demonstrates is that you add an extra field to your CDO titled Unmapped Record,

You then pass ALL records through a Program Builder program which updates any records NOT mapped to a contact in your shared Filter. (your update rule will set that field to 'true'.)

After that the CDO record services evaluates all updated records & sends matching ones to the program Canvas.

The Program canvas deletes any unmapped records passed into it.


The Shared Filter:


Very simply your shared Filter just contains All contacts in your contact table.

Most simply this is achieved by filtering on contacts whose Email Address contains '@', however if your instance is enabled for blank email addresses then also you should include all records whose email address field is blank.

full filter.PNG


The Update Rule:


Create an update Rule (Audience > Tools > Data tools) of entity Type Custom Object, which will be configured to set the 'Unmapped Record?' field in your Custom data Object to equal the value ‘true’

Update Rule.PNG

The Program Builder Program


Now you create a program Builder Program that takes Entity Type: CDO Records (selecting your chosen CDO) & the flow needs to be as follows:

Program Builder.PNG

The decision step verifies if the record has a mapped contact within the specified filter (Which should include all contacts.)


If the Record has no mapped contact then the Update Rule is run in Step 100, setting that record's value in the Unmapped Record field to 'true'

The CDO service will detect that the record was modified and because the condition is now met, the record will be pushed into your Program canvas.


The Program canvas.


Very simply, this receives the record passed into it, verifies if the record has a mapped contact (it should not have) & then deletes the record accordingly.

If any records happen to sneak in that still have mapped contacts, they are excluded (I added a week wait step just for testing purposes)

Program Canvas.PNG


The CDO Record Services


To configure your CDO record services within your CDO:

Choose Custom Object > Custom Object Record Services

Choose Modified Data

Choose ‘Add Processing step

From the Add single Processing step option choose ‘Add to step in Program’  (this will route to your Program Canvas)

On the setup screen name your service.

Choose Custom Object records from Entity Type

In ‘This Processing Step Gets Executed’ set it to conditional:  only when the field Unmapped Record = “true”

Once this is set up you need to remember to Enable the service.

Enable CDO service.PNG

Once this is all tied together, you should go to your Program builder & in the start step (Step 000), Add Members to step & add ALL CDO records.

To do this choose source: your CDO & do not restrict the members.


Due to the performance limitations of CDO services, if large volumes of records are involved. pushing these through during prime business hours could have a performance effect on your instance.
For very large volumes of records it is recommended to pass them through the program Builder in smaller batches.

Good Luck!

Filter Blog

By date: By tag: