Skip navigation

If you've explored Custom Objects beyond just collecting incoming data, you've probably noted that there are only a few ways to enter a Custom Object into a Program to modify it. However, there’s no equivalent of Program Feeders for Custom Object records as there is for Contacts – using a Shared Filter that is periodically evaluated.


The best way to “feed” Custom Objects into a Program based on field values in those records is using Service Actions for “Add to Step in Program Builder”.


This how-to article describes how to use Custom Object Service Actions in conjunction with the Form Submit Cloud Connector to dynamically feed Custom Object records into Programs. It is not intended as a step-by-step guide for creating any of the assets described in this design.


CAUTION: This design will fail if you have more than one Custom Object record in this object per Contact record (i.e., email address), as the Custom Object record update will be inconsistent from the Form Submit. Further, ideally but not required, your Custom Object will have a Unique Code of “Email Address” used to map the record to the Contact. Assuming your data model meets these criteria, let’s get started:


1. Create a Form for the Cloud Connector.


You will need to include at least Email Address as a Form Field and a Processing Step of “Update Custom Data Object - With Form Data”, in which you’ll select the Custom Object containing the records to be entered into the Program and map at least Email Address. You can certainly chose to add additional Form Fields and Processing Steps to this Form, but this outlines what you’ll need at a minimum for this design to function.


In the screenshot below, I’m capturing another data point for “Last Action Type” in this Processing Step, coupled with setting a datestamp in “Last Action Date” in an additional Processing Step for “Update Custom Data Object - With Custom Data”. These pieces of information help with auditing by what and when the Custom Object record was updated and can also help prevent infinite loops described at the end of this article.


2014-07-29 05_53_35-Eloqua 10.png


2. Create a Program for Contact records, including a Step for Cloud Connector with type of “Form Submit (Contact)”. Just a quick references of what this Step looks like in Program Builder:


2014-07-29 06_01_52-Eloqua 10.png


To configure the Cloud Connector, select the Form that you created in the previous step, and then map the Contact fields and static values to the appropriate Form fields:


2014-07-29 06_05_45-Mozilla Firefox.png


3. Create a Shared Filter to use as a Feeder for this Program. This Shared Filter will contain the rules used to define which Custom Object record you wish to ultimately feed into the Program, but keep in mind that it will return Contact records.


If you want to modify Custom Object records based on values in fields on that Object, you’ll need to use the Filter Criteria “Has Linked Contact in Custom Object”:


2014-07-29 06_09_24-Eloqua 10.png


4. Create the Program into which the Custom Object records are to be fed. In this Program, you’ll include Steps with Update Rule Sets, and any other Actions applied to the Custom Object records.


IMPORTANT: In your Program design, be sure that you create an exit path for records that have already been appropriately modified, so as not to save the record again. If you do not, you will create an infinite loop with the Modified Data Action Service (see step 5. below), in which the record is updated, triggering the Modified Data Action Service, which again enters the record into the Program, where it again saved, and so on. Here's an option for how this exit path might be implemented using a Decision Rule:


2014-07-29 06_13_31-Eloqua 10.png


5. Create an Action Service for Modified Data on the Custom Object.


2014-07-29 06_19_32-Custom Object Services.png


Select the type “Add to Step in Program Builder”. In the Parameters,you’ll need to select “Custom Object Records” as the Entity Type, and the Program Name and Step into which the record should enter.


2014-07-29 06_21_30-Edit Processing Step.png


An alternative to preventing an infinite loop is conditionalizing this Processing Step to execute based on the presence of a value in a field on the Custom Object record. Using the example of the field "Last Action Type", you could set this field with a static value via the Form Submit Cloud Connector (e.g., "Ready to Update"), conditionalize this Step to only execute when that value is present, and run an Update Ruleset within the Custom Object Program to change the value in that field. As a result, when the record is modified, triggering the Action Service again, the record no longer meets the condition on the Step and the record is not added back into the Program.


NOTE: If your Form in step 1. above is creating records in the Custom Object rather than only updating existing ones, you will need to create Action Services for both Modified and New Data.


There are a number of scenarios in which you might need to update data values on a Custom Object, and once you’ve got the Custom Object record in a Program, your options for creative applications really expand!

Filter Blog

By date: By tag: