Discussions

Missing in new SFDC App: The ability to add Campaign Members to the SFDC App

Regan J BrownRegan J Brown Posts: 9 Red Ribbon
edited July 10 in Dream It

Greetings Eloqua Dev team!  In the native SFDC integration, we were able to update and create campaign members with external calls. Now, using the actions, we are no longer able to update campaign members.

In the legacy program the same external call was creating and updating members as long as the Lead ID and Campaign ID were present.

The new setup is structured the same way and we pass the Lead ID and Campaign ID the call fails to update stating the record already exists.

We rolled out the new SFDC App in our instance in February and have fully transitioned all of our programs to the new canvas using the new app. However, we had to reactivate one of the old native programs so that it can handle this update to campaign members as it is an essential feature that our sales teams rely on for campaign member reporting.

Please, please add this functionality to the SFDC App before the native integration sunsets February 2021. Our sales teams are heavily dependent on it. It seems odd that you would not have all of the same functionality in the new app that you had in the native integration.

Thank you for your consideration!

-Regan

32 votes

Active · Last Updated

Comments

  • Nathan Nemirovski-OracleNathan Nemirovski-Oracle Principal Product Manager Posts: 31 Employee

    This functionality is already available in the the SFDC App. Please use Eloqua Campaign Responses to create new SFDC Campaign Members and update members' status in Salesforce.

  • Regan J BrownRegan J Brown Posts: 9 Red Ribbon

    This functionality is already available in the the SFDC App. Please use Eloqua Campaign Responses to create new SFDC Campaign Members and update members' status in Salesforce.

    Hi Nathan,

    The solution you provided is a 1:1 scenario and assumes that contacts are only ever responding to the same campaign. Our leads respond to multiple campaigns across multiple brands.

    In the legacy setup, we did not have to worry about keeping track of the member id and someone could respond to as many campaigns as they like and all memberships would get updated as long as there was a Lead/Contact ID and Campaign ID.

    This appears to be 100% a limitation in the new SFDC App. According to Eloqua support the new app does not support the SFDC REST API which I am assuming allows the legacy external call to create and update in the same action. You do not need a separate Create Campaign Member and Update Campaign Member. It strictly uses the email address and SFDC Lead ID and/or Contact ID and then the SFDC Campaign ID to generate the call. The campaign member id is not required in the legacy logic.

    Below is an example of why the “update” wouldn’t work if someone is responding to multiple campaigns:

    Using the Contact Table for Create and Update Campaign Member

    • Contact ABC responds to a Brand-A campaign. Lead is Created/Updated and Campaign Member is created and we pull back the Campaign Member ID into Eloqua on the contact table.

    •Now Contact ABC either responds to another Brand-A campaign or another campaign from Brand-B. Lead is Created/Updated and Campaign Member is created and we pull back the Campaign Member ID into Eloqua on the contact table. This new ID overwrites the initial one.

    •If Contact ABC responds again to the first Brand-A campaign, at this time you will no longer have the Campaign Member ID to make the update to our initial campaign member. We now have a different Campaign Member ID on the record so the wrong member will get updated in SFDC. If the Campaign Member ID is blank, Eloqua will try to create a new member and the action will fail stating the member already exists

    Please keep this idea open for consideration for the product roadmap. We cannot fully migrate off of the native SFDC integration without this functionality.

    Thank you,

    Regan

  • brianjwbrianjw Posts: 5 Green Ribbon
    edited July 31

    I also need this functionality. Our team does not use the Response Actions on the SFDC app. We used the native integration to create new campaign member records with the SFDC Lead/Contact ID and the Campaign ID. Since we moved to the SFDC cloud app, the action creates numerous errors about the campaign member already existing.

    We need the ability for Eloqua to overwrite the status with the latest one, and not trigger an error, similar to how the native integration functions. The Response Action solution does not work for us and we do not want to go that route.

  • David SilvaDavid Silva Posts: 5 Red Ribbon

    Hi Nathan,

    The solution you provided is a 1:1 scenario and assumes that contacts are only ever responding to the same campaign. Our leads respond to multiple campaigns across multiple brands.

    In the legacy setup, we did not have to worry about keeping track of the member id and someone could respond to as many campaigns as they like and all memberships would get updated as long as there was a Lead/Contact ID and Campaign ID.

    This appears to be 100% a limitation in the new SFDC App. According to Eloqua support the new app does not support the SFDC REST API which I am assuming allows the legacy external call to create and update in the same action. You do not need a separate Create Campaign Member and Update Campaign Member. It strictly uses the email address and SFDC Lead ID and/or Contact ID and then the SFDC Campaign ID to generate the call. The campaign member id is not required in the legacy logic.

    Below is an example of why the “update” wouldn’t work if someone is responding to multiple campaigns:

    Using the Contact Table for Create and Update Campaign Member

    • Contact ABC responds to a Brand-A campaign. Lead is Created/Updated and Campaign Member is created and we pull back the Campaign Member ID into Eloqua on the contact table.

    •Now Contact ABC either responds to another Brand-A campaign or another campaign from Brand-B. Lead is Created/Updated and Campaign Member is created and we pull back the Campaign Member ID into Eloqua on the contact table. This new ID overwrites the initial one.

    •If Contact ABC responds again to the first Brand-A campaign, at this time you will no longer have the Campaign Member ID to make the update to our initial campaign member. We now have a different Campaign Member ID on the record so the wrong member will get updated in SFDC. If the Campaign Member ID is blank, Eloqua will try to create a new member and the action will fail stating the member already exists

    Please keep this idea open for consideration for the product roadmap. We cannot fully migrate off of the native SFDC integration without this functionality.

    Thank you,

    Regan

    Regan,

    As a note, the Briefcase Step in the Native Integration (and the Response Action in the CloudApp) doesn't work in the way you are stating (I think).  A lot of this is a black box, but this is how I believe it works since this is how it behaves:

    1) There is a Campaign Member table in Eloqua that stores each Contact's Campaign Member records.

    2) When the Campaign Member record is created in SFDC, the Campaign Member record receives the SFDC Campaign Member ID.

    3) Any updates to the Campaign Member status are based on the priority of the Response Rules.  In other words, the Status will only get updated if the Priority of the new Response is higher.

    The power of the Briefcase Step is it can push through old Responses.  For example:

    1) Contact record is not yet in SFDC.

    2) Contact becomes a Member of Campaign 1 in Eloqua.

    3) Contact becomes a Member of Campaign 2 in Eloqua.

    4) Contact is created as a Lead in SFDC.

    5) Contact moves through the Briefcase Step.

    6) BOTH Campaign Member records are created in SFDC.

    So, you can see the convenience of the Briefcase Step.  You don't ever have to keep track of the Campaign Member IDs of the various Campaigns.  In your example, Eloqua keeps track of the IDs behind the scenes.  Every time there is a new Campaign Response, send the Contact through the Briefcase Step and the Campaign Member will be created (or updated) appropriately in SFDC.

    That being said, there are some times use cases for using the old Campaign Member association method.

  • Regan J BrownRegan J Brown Posts: 9 Red Ribbon

    Regan,

    As a note, the Briefcase Step in the Native Integration (and the Response Action in the CloudApp) doesn't work in the way you are stating (I think).  A lot of this is a black box, but this is how I believe it works since this is how it behaves:

    1) There is a Campaign Member table in Eloqua that stores each Contact's Campaign Member records.

    2) When the Campaign Member record is created in SFDC, the Campaign Member record receives the SFDC Campaign Member ID.

    3) Any updates to the Campaign Member status are based on the priority of the Response Rules.  In other words, the Status will only get updated if the Priority of the new Response is higher.

    The power of the Briefcase Step is it can push through old Responses.  For example:

    1) Contact record is not yet in SFDC.

    2) Contact becomes a Member of Campaign 1 in Eloqua.

    3) Contact becomes a Member of Campaign 2 in Eloqua.

    4) Contact is created as a Lead in SFDC.

    5) Contact moves through the Briefcase Step.

    6) BOTH Campaign Member records are created in SFDC.

    So, you can see the convenience of the Briefcase Step.  You don't ever have to keep track of the Campaign Member IDs of the various Campaigns.  In your example, Eloqua keeps track of the IDs behind the scenes.  Every time there is a new Campaign Response, send the Contact through the Briefcase Step and the Campaign Member will be created (or updated) appropriately in SFDC.

    That being said, there are some times use cases for using the old Campaign Member association method.

    Hi David,

    Thank you for your feedback. Unfortunately, the Campaign Response Action is not a viable solution for us. We have a lot of different products that use a single form, ie: all of our product trial downloads use one form. Each form passes unique hidden values for each product and we use lookup tables to assign SFDC campaign IDs. 

    I do not believe it will be possible to continue using the shared forms if we switch to the Campaign Response Action. The shared forms are necessary for our company as we have 12 different brands in Eloqua with dozens of products and hundreds of gated resources across our websites.

    If you know of a workaround for this that would allow us to easily convert to the Campaign Response Action using shared forms, I am all ears!

    Quick question though: is the briefcase step still available in the new app, in the Campaign Response Action? Or does it go by a different name?

    Thanks again,

    Regan

  • Christopher Campbell-OracleChristopher Campbell-Oracle Director, Product Management Posts: 73 Employee

    Hi Nathan,

    The solution you provided is a 1:1 scenario and assumes that contacts are only ever responding to the same campaign. Our leads respond to multiple campaigns across multiple brands.

    In the legacy setup, we did not have to worry about keeping track of the member id and someone could respond to as many campaigns as they like and all memberships would get updated as long as there was a Lead/Contact ID and Campaign ID.

    This appears to be 100% a limitation in the new SFDC App. According to Eloqua support the new app does not support the SFDC REST API which I am assuming allows the legacy external call to create and update in the same action. You do not need a separate Create Campaign Member and Update Campaign Member. It strictly uses the email address and SFDC Lead ID and/or Contact ID and then the SFDC Campaign ID to generate the call. The campaign member id is not required in the legacy logic.

    Below is an example of why the “update” wouldn’t work if someone is responding to multiple campaigns:

    Using the Contact Table for Create and Update Campaign Member

    • Contact ABC responds to a Brand-A campaign. Lead is Created/Updated and Campaign Member is created and we pull back the Campaign Member ID into Eloqua on the contact table.

    •Now Contact ABC either responds to another Brand-A campaign or another campaign from Brand-B. Lead is Created/Updated and Campaign Member is created and we pull back the Campaign Member ID into Eloqua on the contact table. This new ID overwrites the initial one.

    •If Contact ABC responds again to the first Brand-A campaign, at this time you will no longer have the Campaign Member ID to make the update to our initial campaign member. We now have a different Campaign Member ID on the record so the wrong member will get updated in SFDC. If the Campaign Member ID is blank, Eloqua will try to create a new member and the action will fail stating the member already exists

    Please keep this idea open for consideration for the product roadmap. We cannot fully migrate off of the native SFDC integration without this functionality.

    Thank you,

    Regan

    Hi Regan,

    Is the desire to be able create and update campaign members solely based on a SFDC campaign id and a lead or contact id?  Very specifically, if a contact submits a form related to two different campaigns, you would like to be able to create two campaign members, one for campaign 1 and a second for campaign 2 (using the campaign id and lead or contact id from Eloqua contact fields).  And then, if the person submits another form related to campaign 1 that produces a different response status, the campaign member for campaign 1 is updated, while the campaign 2 campaign member remains?  Can you please confirm this point?

    You are correct that the above is possible with the SFDC native integration that Eloqua offers.  This was originally possible because the SFDC APIs (v15 and prior) supported creating AND updating (upsert) campaign members using only the campaign id and lead or contact id.  With v16 of the SFDC APIs, this capability was removed.  With SFDC removing support for API versions older then v16, we have reworking the native integration to continue to support the upsert functionality, however it comes at a cost of additional SFDC API calls as well as a performance degradation (this is only a concern when large volumes of campaign members are processed).  We are looking at options to bring a similar capability to the integration app as well.

    Thanks,

    Chris

  • Hi Regan,

    Is the desire to be able create and update campaign members solely based on a SFDC campaign id and a lead or contact id?  Very specifically, if a contact submits a form related to two different campaigns, you would like to be able to create two campaign members, one for campaign 1 and a second for campaign 2 (using the campaign id and lead or contact id from Eloqua contact fields).  And then, if the person submits another form related to campaign 1 that produces a different response status, the campaign member for campaign 1 is updated, while the campaign 2 campaign member remains?  Can you please confirm this point?

    You are correct that the above is possible with the SFDC native integration that Eloqua offers.  This was originally possible because the SFDC APIs (v15 and prior) supported creating AND updating (upsert) campaign members using only the campaign id and lead or contact id.  With v16 of the SFDC APIs, this capability was removed.  With SFDC removing support for API versions older then v16, we have reworking the native integration to continue to support the upsert functionality, however it comes at a cost of additional SFDC API calls as well as a performance degradation (this is only a concern when large volumes of campaign members are processed).  We are looking at options to bring a similar capability to the integration app as well.

    Thanks,

    Chris

    My scenario is the update existing campaign member for new response date/status and not needing the campaign member ID to do it. 

  • Regan J BrownRegan J Brown Posts: 9 Red Ribbon

    Hi Regan,

    Is the desire to be able create and update campaign members solely based on a SFDC campaign id and a lead or contact id?  Very specifically, if a contact submits a form related to two different campaigns, you would like to be able to create two campaign members, one for campaign 1 and a second for campaign 2 (using the campaign id and lead or contact id from Eloqua contact fields).  And then, if the person submits another form related to campaign 1 that produces a different response status, the campaign member for campaign 1 is updated, while the campaign 2 campaign member remains?  Can you please confirm this point?

    You are correct that the above is possible with the SFDC native integration that Eloqua offers.  This was originally possible because the SFDC APIs (v15 and prior) supported creating AND updating (upsert) campaign members using only the campaign id and lead or contact id.  With v16 of the SFDC APIs, this capability was removed.  With SFDC removing support for API versions older then v16, we have reworking the native integration to continue to support the upsert functionality, however it comes at a cost of additional SFDC API calls as well as a performance degradation (this is only a concern when large volumes of campaign members are processed).  We are looking at options to bring a similar capability to the integration app as well.

    Thanks,

    Chris

    Hi Chris,

    Thank you for your response. Our main issue is that the campaign member ID is not required in the legacy logic.

    Your description of the desired campaign response outcome in paragraph one seems like an accurate description of what we are trying to achieve. We want the same lead to be able to respond to the same campaign multiple times and update on the campaign member each time. New new app creates an error and will not allow you to update the campaign member.

    Thank you again for explaining about the APIs. I appreciate that you are looking at options to bring a similar capability to the app.  Do you anticipate that this will be released before the native integration sunsets in Feb 2021?

    If not, will we still be able to use the native integration for the purposes of updating campaign member until this functionality is available in the app?

    Unfortunately, the 'Campaign response' action is not a scalable solution for us based on how we use forms and assign campaigns, in addition to the large amount of campaigns and forms we have. (For reference, we have two Eloqua instances and manage 12 brands across these instances.)

    Thank you,

    Regan

Sign In or Register to comment.