Wrong SF campaign ID if C&P form contains no SF campaign ID?

[Carl Paulsen]

We've seen a number of cases recently where a user sets up a C&P campaign and assigns a SF campaign ID to it. Then they set up a form, but leave the SF Settings portion of the form blank (no ID assigned there). It used to be that all forms within a C&P campaign would send transactions into the SF campaign assigned to the C&P campaign. If forms used different SF Campaigns, those campaigns would override the SF campaign assigned to the C&P campaign. But now if a user does not assign a SF campaign to each form used within a C&P campaign, the transactions fail to post (even if they have assigned a SF campaign ID to the broader C&P campaign). The error we see is that the campaign ID is not correct - in fact the ID that displays in the error is not even in the SF format of IDs.

This appears to be a change in the way data is posted to SF. When I look at the raw data for a transaction that fails, here's the xml for the external campaign ID <CampaignExternalID>637393219632786417</CampaignExternalID>. As you can see, that string of numbers is nothing like a SF campaign ID.

The problem we're having is that we bypass the C&P record handling and instead parse the raw xml data and create or assign records using our own code. We do this for a number of reasons I won't explain right now (suffice it to say our system works better when we do this). The <CampaignExternalID> data has always shown either the SF campaign ID stored in the donation form or, if no ID is assigned in the form, the ID assigned to the C&P campaign. But that is not happening now. We've had multiple posts to SF where the external campaign ID is like the above ID. As you can image, if we try to post an opportunity record using a campaign ID like above, it will fail. But we've also found that if the user assigns a SF campaign ID in the form itself, the problem resolves.

Has there been a change in how data is posted in the xml related to campaign IDs that is sent into Salesforce? Alternatively, is there a new requirement that every Form has to be assigned to a SF campaign? In either case, why would a number like the above be posted with the xml for external campaign ID? Note our code can handle if there is NO campaign assigned (we assign it to a default campaign in that case). But if there is an incorrect ID, we have not anticipated that. We could, perhaps, program to ignore IDs that don't begin with "701" (the prefix for campaign IDs in SF) but even that is not a perfect solution since what is being posted in the field above could well start with "701."

Thanks for any light you can shed on this new behavior.

[Carl Paulsen]

Just as followup, when our user changes the form to assign a SF campaign ID to it, all subsequent transactions successfully post to SF. But transactions prior to that change continue to fail to re-post. Those transactions must be entered manually. In other words, the odd ID in the <externalcampaignID> xml data is stored with the transaction.

[CnP.LiveSupport.AB]

Given the historical confusion with how Salesforce Campaigns are assigned, I can understand the interest in parsing it yourself.

There have been multiple changes to how the Salesforce Campaign is assigned - although they have all been well intentioned, they haven't really overcome the inherent issues:

• there is data that is specific to a transaction
• there is data specific to each line item on the transaction
• donation forms are typically collecting data at a transaction level- since there is only one line item
• our Saleforce users pretty much only care about the Campaign assignment on the Opportunity - representing the line item

Please review the recently published article on "Assign Salesforce Campaigns". The cleanest, simplest way to assign Primary Campaign Source on an Opportunity is based on the product code, aka SKU.
Once you get comfortable with SKUs and implement them throughout - nearly all "campaign confusion" goes away.

Regarding your specific questions:

• Has there been a change in how data is posted in the xml related to campaign IDs that is sent into Salesforce? Yes, overtime there have been quite a few. The primary change happened a couple of years ago when PaaS stopped automatically assigning the "transaction campaign" if no "item campaign" had been specified.

• Is there a new requirement that every Form has to be assigned to a SF campaign? No. A good rule of guidance with our products is that any value specified at a more granular level will override a value set at a broader level.

For example, a Campaign can have many forms: so if there is a Salesforce Campaign specified for the Campaign, and also for the form, the form value will override the CONNECT campaign one.
But if you think about it, the form still represents "the transaction" - so it is still passed as a "transaction" campaign.

• Why would a number like the above be posted with the xml for external campaign ID?

The most likely reason is that someone entered an invalid Campaign Id where the Salesforce Campaign information was specified. C&P is mostly a "push" integration with Salesforce - when you assign a Salesforce campaign in CONNECT - it is matching manually on the characters listed for the Campaign name or the Campaign ID. The program assumes that if an ID is specified, it is correct - but there's no validation. And CONNECT is not querying Salesforce to find out what Campaigns are available.

Another helpful point to note with Salesforce Campaigns - they have to be active for our software to acknowledge their existence.

Programming your code to validate an incoming Campaign Id that is not formatted correctly would be kind of a messy, buggy solution - I would really recommend going with SKUs to assign campaigns. Assigning a Salesforce Campaign by SKU always overwrites any setting coming from CONNECT, because SKU assignments are evaluated after the data arrives in Salesforce, just before creating the transaction record and the opportunities.

SKUs can make a robust automations of recording transactions in Salesforce beautiful, but the upfront planning tends to discourage customers - I wish I could talk every customer into using SKUs.

Recommended: Power of SKU article

Does that help clarify?

[Carl Paulsen]

Thank you, that does clarify some things and I really appreciate all the info you've posted! I think I have most of what I need. The person who set up the campaign and form (and who is a strong SF and C&P user) swears there was nothing in the form field for campaign ID. The campaign ID was only in the C&P campaign. I don't know if she set anything at the item level but I don't think so (I'll check). When she went in and fixed the problem, all she did was add the campaign ID to the form. Thereafter it worked OK. If there were anything at the item level I'd expect the subsequent transactions to also fail based on what is mentioned above.

Note that we reserve SKU for Opportunity record type (since we need to assign various record types and there is no option in the C&P system we're aware of for assigning that value). We have code that assigns opportunity record type if that is entered into the SKU. We also allow true SKU values in that field, so trying to include a third piece of data for campaign ID seems like it will complicate our programming. I don't think that's an option for us, so understanding how that odd value got into the campaign ID would be helpful.

The other problem with SKU is that using that field for anything other than unique SKUs for products (e.g. assigning all items to the same SKU) complicates use of the virtual terminal (or at least has in the past).

If you have any other ideas we'd be grateful to hear them.

[CnP.LiveSupport.AB]

If you want to share some example order numbers where you are seeing this "<CampaignExternalID>637393219632786417</CampaignExternalID>" format, I will be glad to look into it. Right now, I'm not even sure which organization you are experiencing this issue with.

SKU is the option in the C&P system for assigning Record Type. It's the best option for assigning all custom values in Salesforce, but does require some advance planning, so other options for assigning Salesforce campaign have been added, but they can cause confusion.

The recently published versions of Power of SKU article and Assign Salesforce Campaigns should make Salesforce campaign assignment make a lot more sense, but without knowing more about the specific needs of your organization/s, I can't offer additional advice.

[Carl Paulsen]

Hi and thanks for sticking with this. The org is the Huron River Watershed Council. One sample order number is 29011-2012020945349948514. I'd love to know what you find out. Thank you!

[CnP.LiveSupport.AB]

I have not forgotten this Carl, our team is continuing to investigate.

[Carl Paulsen]

Great, thank you!

[CnP.LiveSupport.AB]

Carl,

Have you made use of Campaign Lift or the URL parameters with your donation forms?

[Carl Paulsen]

I don't think any of our groups have tried either of these. I assume the URL parameters pull data from either C&P or SF specific to that donor to pre-fill the form, so they would need to get a link specific to themselves so it can be pre-filled? Assuming that system can pull from SF it sounds very useful. I'll look into it more. I can also see the value of the lift system, though that would take more forethought and planning. Thanks for mentioning those.

Not sure I see how that would help with the current problem with SF campaign assignment though. Any word on why that order I mentioned above was given an odd campaign value?

[CnP.LiveSupport.AB]

It was a question that the development team had asked, I think because there is something about those features that could potentially alter how the campaign is added to the XML. Those features are not pulling any information from Salesforce. If you aren't familiar with them, then that is not the issue.

[Carl Paulsen]

OK, thanks. I look forward to anything you all discover.

[CnP.LiveSupport.AB]

We have been able to duplicate the problem by replicating the form, although we are still determining why the problem occurred. Because we have isolated the problem to the form itself, I would suggest re-creating the form (not copying it, saving it as a new name, or recyling it-as that could just copy the problem as well.) Once you've recreated it, obviously replace the code wherever the wrong form was published with the new form.

That way you can avoid the problem occurring again, and of course the old form would still be available for troubleshooting.

[Carl Paulsen]

OK, thanks for the update and suggestion. I'm glad you've narrowed the problem down. I'd love to hear what you find out in the end. Meanwhile I'll try to get that done soon.