Speaker 0: To everyone joining us wherever you are in the world today, my name is Laura Curtis. I’m a marketing automation strategist here at Sercante and I’m going to be your session moderator for today. So make sure that you post any questions you might have in the chat or the Q and A tab. I’m super excited for you to be joining this session all about Pardot External Actions, an intro to them and more importantly, how we build them. So with that, I would like to introduce you to our speaker today, Chris Cornett. And by the way, it’s his birthday today or this week, so please be nice to him with your questions. Over to you, Chris.

Speaker 1: Alright. Thank you so much, Laura. Very excited today to talk to you about all about the external actions. Before we actually jump into it, just want to say I may be making some forward looking statements in this presentation, so please make all your purchasing decisions based on what’s currently available in the market. Really, the agenda today, just want to start off and thank you all for joining. I really do love the opportunities to be able to present to the community and hope this actually helps to share some insights about external actions. So we’ll talk all about why they’re important, what they are, and how they can help marketers. And then wanted to go through some interesting POCs (Proofs of Concept) that I’ve played around with that hopefully will spark some ideas and open up some patterns for everyone to be able to build and implement some really great external actions.

And so with that, I want to start off with the why. So we know that marketers are responsible for growing their brand. They’re also responsible for growing their revenue overall. And for that, they have to use multiple MarTech solutions in order to be able to engage their customers, be able to run their marketing at scale. And so they need this technology to work together. But a lot of times, it feels like they have to work for the technology. And this problem just gets worse because marketer expectations are growing. The number of channels that they need to market across are expanding. As we transform in digital first, we’re changing how we collaborate with teams, how we collaborate with teams and where we collaborate. And as technology advances, we gain even deeper insights into into customers and our prospects, which allow us the opportunity to be able to have deeper and richer campaigns. And to solve all of this, the MarTech ecosystem or the MarTech world has really adapted and expanded and provided solutions to help solve various pieces of these challenges. But that introduces a very fundamental problem, which is how do you make all of these systems work with the marketers flow and allow them to be as efficient as possible? Because in a disjointed marketing ecosystem, you have a lot of reduced weight or you have a lot of waste that gets introduced. You also have a lot of manual interventions that are required to have things work across systems. And when you actually are able to get these in in harmony, you’re really able to expand what you are capable of automating, removing work off of the plate of marketers. You also are able to help them to be able to stay in their flow so that they can gather the information in the context where they currently are instead of needing them to to switch applications, for example, which can take someone out of their current thought process. Also, you want to have effective collaboration. You want to make sure that the information is going to the person where they’re actually going to see the details and where they’re already actively monitoring so that they don’t have to have to look at other systems and miss potential leads. And all of this is a goal to be able to help reduce the manual effort for marketers so that they are more effective and they have more time to really focus on their primary job, which is marketing.

And so that’s why Account Engagement has been working on our extensibility and integratability within our overall tool suite. At the center of this, we have API v5, which is really around being able to pass data and be able to pass data between systems. Then we introduced External Activity, which added a way to be able to supercharge automations by triggering it based on triggering them based on external activity that has happened in a third party system. Then we continued this journey with External Actions, which I’m here to talk to you about today. So what are external actions and and why are they important? Because there are a lot of capabilities that exist in the third party systems that you may want to trigger as part of your Engagement Studio program. And that’s exactly what external actions are designed to enable, allowing you to be able to do things like register someone for a webinar, kick off an external workflow, or send someone an SMS text opening up new channels. The great thing about this is that it leverages Salesforce technology called Invocable Actions, providing you options on how to build these from Apex, External Services, and or Salesforce Flow, providing you low-code to full-code options in order to implement these. And to make it even better, we’ve expanded the metadata so that you now can package external actions as a Marketing App Extension. This makes it easier so that you can test them in a sandbox and be able to promote them to production. Or you can even list this on AppExchange in order to provide customers a no-code experience for external actions or an integration overall.

So now so instead of hearing it from me, I’ve done an interview with Harry Berry, who is a long time Saint Louis developer. He has created a lot of, he has created actually the proof of concepts that we’re going to review today. So, Laura, why don’t we go ahead and kick off the interview? Welcome, Harry. Would you like to introduce yourself?

Speaker 2: Why? Why? Yo. My name is. I made external actions that got.

Speaker 1: Indeed. So how long have you been in development?

Speaker 2: Well, Chris, development is a love of mine. It’s like taking off in a rocket ship, laying it on the moon, and finding it’s made over.

Speaker 1: I really love your enthusiasm. Now what led you to external actions?

Speaker 2: My. My marketers wanted help, and I wanted happy. It was like a win later situation, except for the blues was a win. What kind of

Speaker 1: help were they looking for?

Speaker 2: They have all kind of service. They look like a kid in a candy store. Problem is they can’t reach all the candy, so I want to give them a ladder. External actions prove to be a cake ladder. Well,

Speaker 1: that is what we like to hear. How did you find working with external actions? It was great.

Speaker 2: Once I got the hang of it, it was like eating a hot dog. Delicious. You think they called him hot dogs? Because once you get one, you say hot dog.

Speaker 1: I really don’t know, Harry. Can you walk me through the steps you followed to build external actions?

Speaker 2: I did. It was straightforward. Build your invocable action and pick your external action record. Then you used the external act. It’s as simple as one, two, four.

Speaker 1: Why didn’t you use 3?

Speaker 2: That number scares me. Okay. Interesting. Well, it

Speaker 1: was a pleasure talking with you, and thank you so much for letting us walk through your cool external actions. Any last words?

Speaker 2: Why will someone give me a hot dog? Hot dog.

Speaker 1: Alright. Well, I appreciate y’all sitting through that. You may not know this about me, but SNL is is a love of mine, especially the nineties. So hopefully, you learned a little bit of something, and it was entertaining at least.

So now let’s look at the proofs of concept that Harry Berry that Harry Berry created and that we’re going to talk about today. The first one is sending an SMS text. So really being able to engage prospects through SMS is a growing desire of marketers and has been something that marketers have been expanding on. And so there’s providers like Twilio that make it easy to be able to manage your SMS services. This integration uses Named Credentials as an example of how you can leverage External Services to build your vocal action and and is ultimately an external action. The next one we’re going to walk through is we’re going to go through an automation subflow. This is really just a concept in it of how could you actually implement and work with multiple workflow systems in order to be able to have them work in tandem? And in the example and the proof of concept, we’re going to use Salesforce Flow. This one has multiple features that get leveraged or Salesforce components. In order to provide authentication, we use Auth Providers and Named Credentials. This one was built in that this has an Apex invocable action, and then Auto Launch Flow and external actions. Then the last one is triggering a Zap within Engagement Studio so that you can leverage an integration service that already has access to thousands of potential integrations and services, and generalize the patterns so that you can leverage them as part of your integration tool suite. This uses Remote Site Settings, Zapier webhooks, Apex, and external actions as well.

So what is this? So so I’m going to start in the Engagement Studio side. And, basically, I have put all the external actions in this studio or in this program. So when we start the external action, the first thing we’re going to send is Twilio. Or once we start this Engagement Studio program, the first step is to send an SMS text, which is then going to go which is going to make a call out to Twilio. And it’s going to send SMS text to the numbers that we provide here, which include so we primarily just have the body because we already mapped this information, which I’ll show you on the x or in the SMS external action record. This this SMS text gets sent with a link to one of the landing pages. So if they complete that form, then we’re going to run a sub automation workflow in Salesforce flow in order to do some processing. So this is another external action. And the interesting thing we do here, which could be expanded to have potential, you know, multistage processes that you want to execute before that take time before you come back to the Engagement Studio program, we’re using a trigger or we’re using an External Activity to pass the processing back to Engagement Studio. So, essentially, what happens is in this step, it makes a call where we provide information and value that will pass back once processing is complete, and then it runs this Auto Launch Flow that we have set up as an invocable action. This could be essentially anything, any type of processing that’s supported by flow. Here is just kind of a basic proof of concept to pull contact and be able to pull contact and lead information. And then the last step of this to say that this processing has completed is to send the activity back to engage into Engagement Studio that we passed along with the request. Now if they’ve successfully run that workflow, then we’re going to add them and call a Zap. This Zap, all you have to enter is what is the webhook URL, and then you go to this Zapier. So they have a trigger called Catch Hooks. It does require premium, but so does access to Pardot. And so you essentially set up the webhook trigger, and we’ll take a little bit deeper into that shortly. And then it submits the then it’s going to actually submit the person or the prospect and add them to an audience in LinkedIn Matched Audiences. And that’s essentially what this whole flow is going to do.

So let’s take it piece by piece. So we talked about the Twilio SMS text. So this is what the activity record or this is what the marketing app extension record looks for. We we’re going to click into the action type, and we see that it looks like a typical external action if you have seen them before. The invocable action here is actually an External Service called twilioAPI.sendSMSText. Once we select this, it pulls in the action schema. And in this case, we have various we have the properties. The account set is essentially the account identifier for the Twilio account. So we go ahead and prepopulate this information. We have a body, which is going to be the variable information we want the marketers to input. We have a from string, which we can pull and set a default from within Twilio. And then we have a two number, which we set to the recipient phone number. In terms of what we’re going to view for this external action, we only want to display the body because we can auto populate the rest of the information for the marketer so they can be a bit more sufficient. And then we look at the required, and we look at the required information, and we don’t really need to change this, which is going to be a common theme that you see as we go through these. So in this case, you can look at the parameter, and you will see that instead of Apex, this will actually tell you what service is being used. So if this invocable action was created as an External Service, as you can see here, it identifies that. It could be Flow or it could be Apex, which we will show examples of, as we get into the other external actions.

So what is an External Service? It is a way to be able to use OpenAPI specifications in order to help simplify building out the endpoints for an integration. So I just said a lot there. But, basically, what what OpenAPI is is a systematic definition of an API that typically is in JSON or another format called YAML that provide that companies provide that you can then just import here. So this is an example of of an open API specification for the Twilio send. It requires a Named Credential, which I will show you a little bit later. But this is basic authentication into APIs and just need to look this information up on the Twilio side. Once we click next, it goes ahead and it auto populates this operation and tells you what the input parameters are and output parameters, which are what we saw on the external activity record. And then we have it set up, and we have a new invocable action that we are able to use. One thing that I do want to mention about this is some it does generate Apex. So there are opportunities, and there are some valid reasons that you may want to enhance and make it more robust. A good example of this is potentially you want to add some retry logic that then will that then can handle some of the error situations without causing a potential disruption.

So finally, let’s take a look at the Named Credential. This is this is just using a name principle, name credential with password authentication. So with Twilio, the way that they do authentication is they provide you an account number to be your username, and they provide you a password, which is an SSID token that you just enter into that, and then you’re able to authenticate. And so in order to test this, I created a simple flow, because I think we all know that Engagement Studio programs can take time to start up, and I don’t want y’all to have to sit through this through that. But I do want to show you that this is functioning. So, basically, I have a screen and went ahead and just prepopulated a lot of the information, and just have the body here. So when I go ahead and click run, I can type anything into the bar body, and I can click next. And then and then, as you can see, it goes to my phone and sent me the text message. So now you have the ability to be able to send text messages as part of an Engagement Studio program. I think that is very exciting.

But let’s go to the next use case, which is expanding automations by running a sub work workflow. So in this case, we have multiple features. We have multiple features that we need to that are leveraged, and we’ll walk through them very briefly. I’m not going to go through the auth provider and name credentials because this has been covered in a lot of other presentations before, but want to walk you through what the concept is and potentially how this could be expanded to other potential automation systems that you may want to work in concert. So in this case, I just called the extension Automation Tools. This one is dependent on an action and an activity. So the action here is an invocable flow, which is basically just providing in this case, I just provided some basic information to play around with it, which is the business unit ID to send the response back to, the value that you need to match to be looking for on trigger, and then the Salesforce ID so I can pull prospect information or leading contact information and work off of that record. In this case, the view is a business unit ID and a value, which you can see in the Engagement Studio program. And as I mentioned, this is type flow. So, basically, all you do is you create what’s called an Auto Launched Flow. And this is this is what an auto launch flow looks like. You define your inputs as resources, and then you have your processing logic, which here it gets the lead using the identifier or checks to see if there is a lead, checks to see if there is a contact, and then it is pulling the email address and sending in sending an activity to trigger in order to return this back to Engagement Studio processing. I would like to kind of have you think about it, but, basically, this could even be a process where you call one auto launch flow, and then you have a multiday process such as a sales journey that goes through that then ultimately has it then come back to Engagement Studio, say, after a sales review has been completed.

So that covers the second use case in regards to kind of being able or start. There’s actually more information here that I want to share because we showed the flow that becomes the invocable action, And then you can use Apex auto launch flows, which you saw as the last step. So this is the Apex representing that that invocable action that we triggered within that flow. So one thing to note is invocable actions have a lot of use cases. You don’t need you can use them within flow. You can also use them within external actions. And so in this case, it’s actually not intended to be an external action, but it could be. And that’s one of the great things about the reusability of invocable actions. So here, we have a Named Credential, though, which handles our authentication. We have the default extension name, which then lines up if we go back to the record, lines up with the activity record that we create. So for an activity, the key things majority of this is run via an API request. And so the key things from this record that you need to pull is the marketing app extension name, the and the activity name. And so here, we have the inputs. So we just went ahead and set these as defaults to make it a little bit easier for the representation. Now these are invocable actions, which are dependent on so two things, which are annotations that are used in vocable actions, is @InvocableVariable, which you use to define as an input or an output variable into the invocable action. And then there’s another one called @InvocableMethod, which then defines what is the action you actually are going to execute in the invocable action. In this case, we have an input class that has the activity value, business unit ID, and the email that we’re going to create the activity for. Then we have an activity output, which is just a simple class to be able to provide back a success value and message, which is useful in in doing your manual testing. And then finally, we have a Pardot activity class representing a Pardot activity request, which then makes it easy for you to be able to build the bot, which has the email extension type and value.

So let’s jump to the method really quickly. So in this part of the method so one thing to note with an invocable action is that it requires a list of inputs and a list of outputs, if you’re going to have, if you are going to have output, void is a valid output. But when you loop through the request, so that means you want to be able to loop through the request, so that’s why we have a fourth loop here. Then underneath this, this is a basic pattern that you can use in order to make API calls. So the first thing is you set up the information for the payload, which in this case is the activity request email. Object, we have an HTTP request, and then we have an HTTP for the call. So the first thing we do is we build the request button. So we’re just mapping email extension names, etcetera, and then we serialize that into the body and add that to the HTTP request. Then we construct the HTTP request with the appropriate content type, the business unit that we want to make make the call out to, which we get from the input, the endpoint that we’re going to send it to using the name credential format. And then, since this is a create, the method is a post. Once we have everything constructed, we simply try to make the request. And if it is successful, then we set the output, that everything was a success. And if it is returns an exception, then we catch that exception. So that’s what the actual Apex code looks like, that we’re using in order to send that request.

So going back to the activity type, or going back to the actual extension, this, again, you have the this is actually going to be an action per auto launch flow that you want to send, and then you just need one activity type in order to do kind of the response signal to continue the Engagement Studio program once this has been like, once your automation has been completed successfully. So that’s that’s the, that’s the proof of concept for an automation subflow, which can allow you to connect a lot of different systems together and be able to kick, as I mentioned, be able to kick off workflows.

And so to kind of add to that, this is very similar to that concept, which is triggering a Zap, which is an integration workflow service. And so in this scenario, we had to do a couple of setups. And so as I mentioned, we’re using a ZAP or we’re using a webhook for this app. So let’s start from the external action record for the Zapier prospect webhooks. So this was built using Apex, which I’ll show you what it looks like briefly. The key properties for this is email, first name, last name. This, you can essentially decide how much prospect information you want to pass. In this case, I just passed, you know, some of the common elements. The next input, which is user which you would want to be the user, is the Zapier webhook URL. So where do you get this information from? It’s actually within the Zapier system. So when you set up a catch hook in webhooks, you go to test, and it actually sets up a webhook for you. So, really, this is what the marketer would copy and input into this external action. So that’s why that’s the one thing that we have enabled for them. So they essentially can select any Zap that they want to leverage, assuming that we have standardized the inputs that are common across the services that they want to use. This uses a unique scenario because webhooks are public endpoints. So within Salesforce, you have to set up remote site settings so it can make these calls and be allowed. So in this case, you can see this entry here, which then enables callouts to hooks.zapier.com.

So to show you this in action, I have a basic Zapier webhook tester. I click run. It has all the inputs that I just discussed with you, and you can click submit. Now I have not published this one, but they allow you to test these requests. And so, essentially, if I click load more, we should see my webhook request come in. Well, I do apologize. Let’s see if we can submit that again. That’s the fun you always get with doing live demos. Alright. I think I’m having some Internet issues, but this is the one that I submitted right before. So it essentially pulls in the different details that we passed, which is cornetchris@christopherdot, cornet dot christopher.cornet@salesforce.com, which is my personal information here. And then once you actually have it set up, when you do set up the actions, in this case, for LinkedIn audience, you can then be able to pull those the email from that webhook request, and you can also be able to pull any other fields that you decide to get added. And so now marketers in this pattern, now marketers have the ability to be able to trigger any Zap that they want, within an Engagement Studio program. So they can have access to any of the thousands of of implementations that Zapier supports, and this could be replicated in, essentially, in any integration service.

And so that ends the different use cases that I wanted to walk you through today. So I do believe that we do have some time for questions. So we’d love to hear from the audience. And then also and and we’ll do have to do some wrap up, in regards and then we’ll do some wrap up, and I’ll give you some tips on how to get started.

Speaker 0: So, Laura, do we have any questions, from the audience? Let’s head over to the Q and A tab. Let’s have a look. First of all, while I find those questions, Chris, wow. What a session. I think that’s all blown our mind today on how amazing external actions can be and it’s certainly given me and I guess I’m speaking on behalf of the rest of the attendees here, certainly given us some food for thought. We do have a few questions so let me go ahead. We have one from Ali. I’m just going to try and bring this one up on screen. Where is it gone? Okay. So has anyone tried this with WeChat? So a Chinese messages service. Do you think this and external actions could go outside of the realms of some of the case studies that we’ve looked at today and extend to other platforms out there?

Speaker 1: Absolutely. So with WeChat, I’m not sure if there are any special considerations. But, ultimately, if they do have an API to be able to perform the communications, then I see no reason that you would not be able to implement an external action that can leverage that service. You know, with Twilio, I you know, they’re we did play around a little bit with, WhatsApp. And, you know, with their APIs, that’s very possible. So I think it really just comes down to what the provider gives in terms of their extensibility that will that can determine it, but I think external actions is a perfect fit for that type of scenario.

Speaker 0: Wonderful. Thank you for that, Chris. We’ve got another question in that, is saying, the process seems like it requires a developer to be involved. Is that a correct evaluation of this? Or can I can I go and do this as a marketer without a developer helping?

Speaker 1: I would say a majority of cases, a developer is going to be desirable. I do think for Salesforce Flow, if you are doing or want to build some Salesforce processes, that is more in realm of, I would say, a technical admin. And then just as I’ve been playing around with this, you know, it’s, you know, I do think there’s opportunities for External Services to be leveraged, but that requires a little bit more knowledge on the API side. In particular, if something goes wrong, you’ll probably want to have a developer to help you. And then for Apex, I would highly recommend developers you working with the developer on it. I do see you know, since the pattern of those Apex tend to be pretty common, I do see it could be in the realm of possibility for some more technical admins to learn how to, you know, swap out the authentication, swap out the endpoints, and could build them. But that, but, realistically, I would say that’s more in the realm of the developer.

Speaker 0: Excellent. Triana asks, so in the use cases discussed, most were shown using Engagement Studio to trigger that. But can external actions only be leveraging leveraged in this particular way? And if so, would there be any future considerations to increase the Engagement Studio limit? So can we go outside of Engagement Studio when it comes to external actions as well?

Speaker 1: That is a great question. It is only supported today in Engagement Studio. However, it is something that we want to hear more from the community about, which is where else external actions can provide them. So this is something that we’re open to in the future of looking to expand into other automations. But I would say it’s not currently on the roadmap yet. But if we do hear a lot of positive feedback, I could see that

Speaker 0: changing. Yeah, I would say get those ideas in. Get them, thumbs up for that idea, I think. Wonderful. I believe we’ve gone through all of the questions I can see on screen. If you do have any last minute questions feel free to post them in the Q and A tab. Whilst we wait for those a couple of questions coming through I just want to give a huge shout out to our sponsors who without them My Dreaming wouldn’t be possible. So if you do have some time either today or tomorrow, make sure that you stop by the Deselect Blue booth to learn about more about their products and services. And if today’s session or any of the other sessions you’ve been to over the last day or so has whetted your appetite to learn more, ask questions, start to dive into some solutioning. We do have the Genius Bar open until tomorrow when it will close. So the Genius Bar is your kind of one stop shop for that one to one session with an expert to answer any questions you may have. And then finally, if you haven’t already, it is the event of the year taking place tonight. So our after party, our MaDreaming after party, where we’ll also have the MaDreamers award which is going to be celebrating and honouring all the marketers for building out innovative solutions using Salesforce tools. And that kicks off at 4:30 this afternoon eastern time. So if you haven’t already registered for that one, make sure you get yourself over. Let me just do a last check of the questions, Chris.

Speaker 1: Sounds good. And while you’re checking, just wanted to give a little bit of insight into how to get started. So some of the resources and I’d be happy to provide links out after this, if there is a mechanism. But we do have an External Actions Developer Guide that’s available that will walk you through the individual steps, in regards to marketing app extensions, external activity, and external actions. We also have help documentation, which gives you more of an admin perspective of how to help manage these. There is an External Actions Developer Blog out there that takes a more detailed look at the Twilio example and even does some expansions in order to add more robustness to, to those actions. And then, finally, we are in progress working on an External Actions Developer Video Series that hopefully will have out by the end of this year, safe harbor, That will help walk peep that will help walk people through building their first external action, from all the way from authentication or really be able to set up their first external action and be able to play around with an example Apex Apex invocable action, if they so desire. So please keep a lookout for some of these new resources. And as mentioned, we’ll be happy to provide any links to help you get started.

Speaker 0: Wonderful. Thank you so much for that, Chris. I’m with you, Triana, that I love a resource slide. So you will be getting access to these slides and the recording. So we can go out and you can go and find these resources and dig in deeper to external actions. I believe we’ve answered all the questions, Chris. So with that, let’s all go and sign up for the party. Let’s go and powder our noses, get into our best party gear and have a wonderful birthday, Chris. There has been a lot of happy birthday messages on the chat. So take care everybody and enjoy the rest of my dreaming.