The Agentforce Playbook

AutomateSphere Blog Reader
Paused 0:14

“The way we work is changing—and if you’re not adapting, you’re falling behind.”

That quote couldn’t be more relevant to what we’re exploring today.

In this demo, we’re diving into a smarter, more flexible approach to capturing leads and connecting them to messaging sessions. At first glance, it might sound routine—but there’s a twist.

Usually, we handle lead capture and session updates in a single, linear flow. Simple, right? But this time, we’re challenging that pattern. Instead, we’re going to split the process into two separate flows, connected through the powerful concept of context variables.
Here’s what that looks like:

  • First, we’ll capture the lead in one flow. 
  • Then, in a completely separate flow, we’ll attach that lead to the messaging session—all while sharing data seamlessly between them using context. 

It’s a cleaner, more modular approach—and it opens up all kinds of possibilities for future customization and scalability.

Before We Begin: A Quick Checklist

To follow along, make sure you’ve got these basics covered:

  1. Assign the necessary permissions to your Service Agent so it can create leads and update messaging sessions. 
  2. Ensure your Service Agent is properly set up and active. 

⚠️ Heads up: If the permissions aren’t assigned correctly, you might encounter errors when building or testing the flow. So it’s worth double-checking before moving on!

Step 1: Creating the Lead Capture Topic

Let’s start where it all begins—capturing the lead.

To do this, we’ll create a new Topic. I’m naming mine “Lead Capture”, but feel free to give it a name that aligns with your business or use case. The important part is to keep your naming clear and intuitive so your flows remain easy to manage.

This  Topic will serve as the entry point, collecting the essential details from the end user. Once that’s in place, we’ll store that information using a context variable, setting the stage for the second flow to come in and do its part.

Now that our “Lead Capture”  Topic is all set up, it’s time to see it in action—literally.

As mentioned earlier, we’re building this demo using two separate flows:

  1. Lead Creation through Service Agent 
  2. Update Messaging Session through Service Agent

 

Let’s begin with the first one.

Flow 1: Lead Creation through Service Agent

 

This flow is where the magic starts. The goal here is simple: gather user input and create a lead record.

To do that, we’re introducing a few input variables:

  • lastName – Text 
  • company – Text 
  • email – Text 

These variables will pull data directly from the end user—whether it’s through a chat interaction, mechanism in your flow.

Now, here’s the key part:

 

Once the lead is created, we don’t want to lose track of it. So, we’re storing the created Lead record in a variable named LeadRecordId which is available for output.

This variable is our golden ticket. It holds the unique identifier of the newly created lead and will later be used in the second flow when we update the messaging session.

Next up, we’ll build the second flow where we’ll put that LeadRecordId to good use and tie everything back to the messaging session. But first, make sure Flow  is working as expected. Test it, validate the data capture, and confirm that Lead record is getting created.

With our lead creation flow in place, it’s time to take the next step—creating the Agent Action. This is what will allow us to plug the flow into a topic and actually trigger it during a real conversation.

Think of the Agent Action as the bridge between your carefully crafted flow and your chatbot’s brain. Without it, your flow is just sitting there, waiting to be called into action.

When you begin creating the Agent Action, you’ll notice something important:
The interface will automatically display all available input and output variables from the flow. This is where you define how data is passed in and out of the flow during runtime.

🔔 Pro Tip: You must have at least one output variable for the Agent Action to be created.
No output? No action. It’s as simple as that.

So double-check your flow—make sure you’re passing something back. In our case, that might be the LeadRecordId, which the next flow will rely on.

Once that’s confirmed, go ahead and create the Agent Action. Give it a clear, meaningful name so it’s easy to reference when attaching it to your topic.

Once we wrapped up our first flow, I went ahead and created a context variable called LeadRecordId. Why? Because we’re not just storing that lead ID—we’re passing it forward.

Using this context variable, we mapped the output from our Lead Capture action to be available in the next flow. This ensures continuity and lets the second flow pick up exactly where the first one left off.

 Now Enter: Flow 2 — Update Mesaging Session through Service Agent

This is where things get really interesting. In this flow, we’re focused on updating the messaging session with the lead details we just captured.

We’re working with three variables here:

  • recordId – to identify the messaging session 
  • LeadRecordId – pulled from our context variable 
  • Success – an output variable to confirm everything worked, set to return: “Job done successfully”

Sounds good so far, right? But here’s the big question…

“Okay, we’ve created the variables… But how do we actually assign values to them?”

Great question!

This is where context variables step back into the spotlight. When your bot reaches this second flow, it will already know the value of LeadRecordId, thanks to the context we set earlier. It’s like giving your bot memory across flows—super useful when you’re splitting tasks like we are.

For recordId, you’ll usually have that passed in by the platform when the session starts. Just make sure your flow is configured to accept it as input.

As for Success, that’s our friendly confirmation variable. Once the session is updated successfully, we assign it a static value:
✅ “Job done successfully”

This not only marks the flow as complete but also gives us a clean way to log or debug outcomes.

 Context Memory in Action — But Wait, There’s a Twist!

If you’ve been following along, you’ll remember that in our first flow, we stored the created lead record in a context variable called LeadRecordId.

 

Now, in our second flow, we’re using that exact same variable to pass the ID over and update the messaging session. Seamless, right?

So… we’re done?
Well, that’s what I thought too.

But here’s where reality kicked in. 💥

The Misunderstanding: When Agents Act Too Literally

After wiring everything up, I proudly ran the flow expecting the agent to:

  1. Capture the lead 
  2. Automatically update the messaging session 

 

 💥 💥 Spoiler alert: It didn’t. 💥 💥

 

Why?
Because I forgot one crucial detail—agents only do what you tell them to do. Nothing more, nothing less.

To the agent, the instruction was simple:

“Create a lead.”

So it did exactly that.
Lead? ✅
Update session? (not its problem!)

The agent politely stopped there, satisfied with its job. But for us, this wasn’t enough—we needed that messaging session updated too.

 The Fix: Clearer Instructions, Smarter Agent

To bridge that gap, I went back and updated the agent instructions. I added a very specific line:

“Once the lead is created, proceed to update the messaging session through the service agent.”

Here, “update the messaging session through the service agent” is actually the name of our second action—so the agent knew exactly what to do next.

This simple tweak made all the difference.
Now, after creating the lead, the agent doesn’t stop. It moves straight into updating the messaging session—exactly as we intended.

The Final Outcome: Mission Accomplished

With both flows connected, context variables shared, and the agent finally receiving clear, sequential instructions—everything worked like a charm.

It’s a great reminder that even smart systems like agents need a little help in understanding what “done” really means.

More like this: