#Agentforce387 diskutieren mit

My take: Data 360 (Data Cloud) is the real foundation — Agentforce is only as good as the data it can reason over, and most orgs' data is scattered across siloed clouds/systems. Without unified, harmonized data, agents hallucinate or give shallow answers. So Data 360 becomes the prerequisite skill, not a parallel track. 

That said, I wouldn't pick just one — the real value shift is toward professionals who can connect the dots: Data 360 for the data layer, Agentforce for the reasoning/action layer, and Flow/Apex still needed underneath for deterministic actions the agent triggers.  

Pure point-and-click admins or pure backend devs who don't understand this stack end-to-end will feel the squeeze. Integration skill matters too since most real agent use cases pull from external systems, not just Salesforce data. 

If picking one to go deep on right now for career leverage: Data Cloud. It's the bottleneck skill most people are ignoring while everyone rushes to learn Agentforce topics/actions. 

Hi Steffany, 

Yes, packaging the Subagent and its associated Actions is a supported pattern. Agentforce Actions and Subagents/Topics are represented by packageable Agentforce metadata such as GenAiFunction and GenAiPlugin.

Based on the behavior you described, I would separate the packaging issue from the commit issue. 

When you add a Subagent from the Asset Library into Agentforce Builder, Salesforce creates a local independent copy of that Subagent and its Actions for that agent version.

The fact that manually re-selecting the Reference Action and saving allows the version to commit suggests that the copied local Action reference is not being resolved correctly during the initial commit. 

I would recommend:

• Keep the reusable Subagent and Actions defined in Agentforce Assets.
• Retrieve/package the Asset Library definitions rather than depending only on the agent-local copies.
• Verify the GenAiPlugin and GenAiFunction metadata and confirm that each Action reference points to the expected Flow, Apex, Prompt Template, or other reference action.
• After adding the Subagent from the Asset Library, review the copied Actions before the first commit and confirm their Reference Action values.
• Test the same package in a clean namespace scratch org.

If the metadata references are correct and a fresh scratch org still requires manually re-selecting the Reference Action before every first commit, I would treat that as a possible platform/metadata serialization issue and raise it with Salesforce Partner Support rather than building the manual re-selection into the deployment process. 

The workaround you found is useful, but ideally it should not be required for every deployment. 

Hope this helps.

Change the button color in branding, and change the labels under custom labels (English / General / All / Standard)

Hi @Dinesh Somvanshi -  

• Make sure Agentforce is enabled in the Playground.
•  Check Setup > Agentforce for Sales and confirm Lead Nurturing is enabled. 
•  Wait a few minutes after enabling it, then refresh Setup. 
•  Make sure you’re using the Playground created specifically for this Trailhead module. 
•  If Lead Nurturing still doesn't appear, create a fresh Playground and start the module there. This is often caused by the required Salesforce Go provisioning not being available in the current org. 

Hi Aakash, 

For an AI-based ticketing system in Salesforce, I would start with Service Cloud and Case Management, then learn AI Summary and Prompt Builder to understand how Salesforce can automatically summarize support tickets and generate useful insights. After that, focus on Knowledge, Similar Cases, and Case Retriever so the system can identify repeated or related issues from historical tickets and use previous solutions as context. Next, learn Service Assistant and Agentforce for Service to understand how AI can analyze cases, recommend resolutions, retrieve relevant Knowledge articles, and assist support agents. Finally, learn how to connect these capabilities with Flow and Apex so the entire ticket analysis and resolution process can be automated. For your use case, the most important areas to focus on are Prompt Builder, Similar Cases/Case Retriever, Service Assistant, Knowledge, and Agentforce, as these will help you build an end-to-end AI-powered ticketing solution.

Hi Motlatso, 

This template is also referred to internally as "Agentforce SDR" — so if Setup shows the other five but not Lead Nurturing, it's usually one of these: 

1. Edition/license gap. Lead Nurturing (Agentforce SDR) requires specific Sales Cloud licensing tied to Agentforce for Sales — it's not automatically included with every Developer Edition or every Sales Cloud license type, unlike some of the other templates you're seeing. Check whether your org has the Sales Cloud edition/add-on this specific template needs. 

2. Dependent features not yet enabled. This template depends on supporting Salesforce Go features (Einstein Activity Capture, Salesforce Inbox connectivity, Data 360) being available in the org. If Salesforce Go itself isn't provisioned, the guided setup card for Lead Nurturing won't appear even though Agentforce is on. 

3. Region/rollout timing. Lead Nurturing on Agentforce Studio rolled out via the Salesforce Go guided setup experience — if your Developer/Trailhead org was provisioned before this became broadly available, it may not have synced in yet. 

What to try: 

- Confirm you're using a brand-new Trailhead Playground (not a reused org) — this module requires a fresh org per the standard Trailhead guidance. 

- In Setup, search "Salesforce Go" and confirm it's available/enabled — this gates the Lead Nurturing card specifically. 

- If it's still missing after a fresh playground, this is worth a Trailhead Help case, since it may be an org provisioning gap. 

Reference:

Start with a brand-new Trailhead Playground first — that resolves this for a lot of people hitting missing templates.