How do I define a SFDC Task "Type" when created from a Mkto campaign?

[Anonymous]

We have a number of Marketo campaigns that create a task in our SFDC org. However, all of the tasks are being created without a task type within Salesforce.

How do I add the task type field into our Marketo org so that I can define it when a task is created in SFDC? I already verified the logged in sync user's profile has access to read and edit the "type" field on the task object in SFDC.

[Josh_Hill13]

If you are using a Custom Task Type, you will be unable to modify this from Marketo. You may be able to enforce this with Apex code in SFDC somehow.

I did come across a crazy method to do this, possibly on this forum, but I can't find it now. I never tried it.

Can you show us a screenshot?

[Anonymous]

This is the standard "Type" picklist field on the task object within SFDC. It's a standard field, so I'm not sure why it isn't showing up in Marketo. We don't have any custom task types setup either.

When we create a task, it's not setting any value for this field, so it ends up being blank. I've been searching a good two-three solid days looking for a solution to this, and I'm absolutely stuck.

What's prompted this is we are now tracking activities on our opportunities, etc. and I need to be able to filter these Marketo automated tasks from my reports.

[Jep_Castelein2]

Instead of using the standard "Create Task" Flow you could use a Webhook to create the Tasks. You actually need 2 webhooks, one to get an access token and store it in a custom field, the second webhook to create the Task. Below is an example using some attribute, but you can add any attribute you want (as supported by the SFDC REST API).

[Anonymous]

Thanks, this is helpful, but seems way more complex than what I should need in this situation. Defining a value on a standard picklist field in a standard object should be pretty straightforward.

It's like I asked you how to change the oil in my car and you said the only option is to rebuild the engine. There has to be a simpler way.

[SanfordWhiteman]

It's like I asked you how to change the oil in my car and you said the only option is to rebuild the engine.

That's a good metaphor for a lot of Marketo support questions.

There has to be a simpler way.

Well, I don't like the double-webhook method (webhooks are stateless, they're not intended to maintain access tokens) but it will generally work.

You could also send via a single intermediate webhook (more to build, but would look clean in Marketo). This is what we do for advanced SFDC record stuff.

Or you could build in Apex entirely on the SFDC side. In Marketo, supply the desired Task Type as a prefix to the Task Subject ("Demo Completed: 30-Day Trial") then in Apex, strip it out of the Subject and change the Type.

[Anonymous]

Or you could build in Apex entirely on the SFDC side. In Marketo, supply the desired Task Type as a prefix to the Task Subject ("Demo Completed: 30-Day Trial") then in Apex, strip it out of the Subject and change the Type.

This seems to be heading the direction I am looking, thanks for this suggestion!

[Justin_Norris1 · Accepted solution]

Dan Dlugos​

I've also done this with a workflow rule in SFDC keying off a value in the subject line to update task type.

Although the field is standard in Salesforce, Marketo's support for tasks is limited to just a subset of standard fields. That's why you're getting suggestions with work-arounds of various complexity.

If you leverage tasks heavily you can also manage task creation entirely in SFDC (where you have access to the full range of fields) and trigger it off a data value change controlled by Marketo. The latter is an approach I often prefer when you want to add a lot of rich information to the tasks and populate several custom fields.

[Anonymous]

....trigger it off a data value change controlled by Marketo.....

Can you elaborate on this? What data value change would you reference to trigger the task creation in SFDC?

[Justin_Norris1]

Dan Dlugos​

The trigger depends on your use case.

For example, in our own instance we have a task that is triggered when the lifecycle stage changes to "MQL." This kicks of a Process Builder that creates the task for a sales person to follow up.

In your case you may want to create a task every time a certain type of form is filled out or based on some other specific action you define. In that hypothetical example, you could include a flow step within the relevant form programs to stamp a value to a lead field like "Most Recent Form" or just to a more generic field called "Follow Up Action" (or whatever) and then this data value change would kick off the process in SFDC. 

(Important! Make sure to include an action within the process to clear the field after the task is created so that it will trigger again if the person fills out the same form twice.)

Whatever your triggers are, the structure I have found works well for this is that your local programs update a set of relevant data points you want to include in your task (for example, we will set a "Lifecycle Stage Reason" field with details about why the person reached MQL before sending them to a central MQL processing flow). These is good to do using program tokens. Then you have a central process that creates the task and merges in those relevant values.

This combination of setting local values locally and then processing the global activity in a centralized place keeps the structure relatively simple and makes it quite easy to maintain and update.

Here's an example of the action creating the MQL task using a Process Builder in SFDC, where you can see how some of those data values are being merged in to the subject. This could also be done in Apex as Sanford said, and we have done this for more complicated implementations.

---

Justin Norris | Perkuto​​