Still possible to create SFDC Case via Webook, triggered by Marketo form?

[kevinmartinexte]

Hi there,

I've found a lot of posts and info on this but nothing very recent, and I can't get it to work with any of the methods I've tried.

Does anyone know if this is still supported by SFDC? Is anyone actively doing it and able to share their webhook info?

Thank you!

[BenG]

Hi,

It is.  I just ran a test using the web-to-case endpoint and it worked fine.  You can generate HTML to get the endpoint details in SFDC Setup: Web-to-Case HTML Generator.

Alternatively, you could setup your own Apex web service if you had to do something not supported by web-to-case and make it public.  Or, you could use the API or Authenticated web service which would be the most complicated approach and require more than one web hook executing.

[kevinmartinexte]

Hey Ben,

Thanks for the reply. Can I ask if you included the Org ID in the URL or payload? I see SFDC appends it to the endpoint URL but the info I'd found previously included in payload. I keep getting an opaque "200" error code as a response; I've probably missed something simple.

Does the payload also have to have all of the fields declared in the form you generate for it to accept a case creation call?

Alternatively perhaps if you would be willing to share a redacted screenshot of your setup, I can learn and adapt mine accordingly.

Thanks again!!

[Jo_Pitts1]

@kevinmartinexte,

this could easily be done using FlowBoost. 

You'd authenticate into SFDC, then create the case.  You could do all of this based on data submitted via a Marketo form and a smart campaign with a trigger.  This approach would also allow you to grab other data from Marketo that may not have been in the form fill, and even do data enrichment and/or reformatting in Flowboost prior to submitting the case.

I've done similar things in the past, but creating custom objects.  The core logic is identical however.

Regards

Jo

[BenG]

Here you go:

[SanfordWhiteman]

This format will break trivially if any characters in the token require URL-encoding. The plus sign is a prime example.

[kevinmartinexte]

That sounds less than ideal!

Jo suggested FlowBoost—would you be able to provide a high level sense of how we'd approach that? Possible in a single call or would it require multiple?

[SanfordWhiteman · Accepted solution]

Well, the first question is why, specifically, you can’t set encoding=Form/URL.

A common reason is you want to use multiple tokens and one or more of them is pre-URL-encoded — that is, the value stored in the database is already %-encoded, so you can’t risk encoding it again.

---

Jo suggested FlowBoost—would you be able to provide a high level sense of how we'd approach that? Possible in a single call or would it require multiple?

---

There would be (at least) 2 ways to do it w/FlowBoost:

1. FlowBoost Community or Standard: call FlowBoost ’hook first, passing the fields as JSON (FlowBoost always expects JSON). Encode as necessary, write the result back to other custom fields  like URL-encoded First Name, etc.. Then all your fields are pre-encoded and you can make another webhook call to SFDC using encoding=None.

2. FlowBoost Standard: call FlowBoost and have it call SFDC with any mismatched encoding fixed up on the fly (one webhook call total).

[Jo_Pitts1]

@kevinmartinexte ,

FWIW - I have done option 2. in the past, and it was super reliable and robust.  It requires that the client has the standard version of FlowBoost (not expensive).

Cheers

Jo