#Trailhead Support35 diskutieren mit

Hello @Abhay Ram Solanki

Deactivate this checkbox and try the step in Trailhead again

Object Manager --> Opportunity --> Field and Relationships --> Discount Percent Field --> Click Edit --> Uncheck "Always require a value in this field in order to save a record" and Save. 

Also, check these similar issue discussions:

• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007UpAE7SAN
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007X94z4SAB
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007X9pVpSAJ
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007T68W1SAJ
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007bLR0bSAG
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007equsRSAQ

Please check if any other automation (validation Rule, trigger, flow) is activated on the Account object; if any, then try to deactivate it. 

If it is not working, then try in a new, fresh org; it might be the existing record causing the issues in your org. 

• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007VHRHrSAP
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007ah9c5SAA
• https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007ajbxjSAA

Hi Martin!

This looks more like a Salesforce platform/Lightning issue than a problem with your Case layout or workflow configuration. The $A.componentService.hasDefinition is not a function error points toward a Lightning component/record layout issue. 

Since you’ve already found the Salesforce Known Issue, I’d check whether your org is affected and follow the workaround/status provided there. 

You can also try a hard refresh or another browser to rule out a caching issue. If it still reproduces, I wouldn’t make further changes to the Case layout. 

The Known Issue you linked should be the best place to track Salesforce’s fix and any available workaround.

Hi Deepayan, 

The flow structure itself looks reasonable, but "Whoops, looks like there was a problem" is Trailhead's generic checker failure — it doesn't tell you which specific requirement is unmet, so the fastest way to actually find the mismatch is the Debug tool you already have open, not guessing from the builder. 

Use Debug directly (you're already on this screen): 

1. Set "Run the Flow As If the Record Is: Created" (since this flow is meant to fire on new Engagements) 

2. Search for and select a real Engagement__c record in the Engagement_c field that has Potential Donation = True 

3. Click Run, then step through each element in the debug trace — it'll show you exactly what value each field resolved to at the Create Opportunity step, and whether the Opportunity actually got created with the right values 

A few specific things worth double-checking against the exact wording in the unit instructions, since these are the most common reasons this exact flow type fails silently: 

1. Trigger type — your flow triggers on "A record is created or updated." If the instructions specifically say the Opportunity should only be created once, when the Engagement is first created (not on every subsequent update), having "or updated" active could cause duplicate Opportunity creation, which can fail the checker even if the create logic itself is correct. Re-check whether the unit wants Created only. 

2. Stage value — "Prospecting" needs to match the exact picklist API value/label required by the instructions, character-for-character. If the unit specifies a different starting stage, this silently creates a technically-valid Opportunity that just doesn't match what's being checked. 

3. Record Type ID — this is pulled from your "Get Record type" Get Records element. Open that element and confirm the filter criteria is pulling the exact Record Type the instructions specify (by DeveloperName, not just Label — labels can look right but not match the underlying API name the checker verifies against). 

4. Entry condition scope — Potential Donation = True as the only condition is fine if that matches the instructions exactly, but if there's a second required condition (e.g., a specific Engagement Type or Status) that's missing, the flow would still "work" for your test case but fail the checker's own test record, which may have different field values than what you're testing locally. 

Run the Debug trace against a record matching the checker's likely test scenario, and check field-by-field which value doesn't match what's expected — that'll pinpoint it faster than re-reading the builder config.

Hi Vruttika, the error indicates that the Salesforce CLI is not detecting a valid DX project in the current directory. 

From your screenshot, the terminal is running from:

D:\Salesforce\geolocation

First, make sure this folder contains sfdx-project.json. You can verify with:

dir sfdx-project.json

If the file is in a different folder, use cd to navigate to that folder and then run the command again.

For example:

cd D:\Salesforce\geolocation
sfdx force:source:push

Also make sure sfdx-project.json is valid and that you're opening the project root folder in VS Code, not a parent or child folder.

If it still gives the same error, please share the contents of sfdx-project.json and the output of dir, so we can check whether the project structure is correct. 

Uploads succeeding while the agent can't access the file content almost always comes down to the file_upload sub-block in your Agent Script's config block, not the file upload configuration in Setup. That "Configure File Uploads for Agentforce" doc you followed handles enabling uploads at the org/channel level, but Agent Script has its own separate setting that controls whether an uploaded file is actually handed to the reasoning engine. 

In the config block, file_upload.mode must be set explicitly. "auto" is the default handling where uploaded files are made available to the agent automatically. "managed" gives you fine-grained control over which files reach which subagent, but it requires you to explicitly pass @system_variables.uploaded_files (optionally sliced, like @system_variables.uploaded_files[0:5]) into that subagent's action inputs; "disabled" and "error" both reject uploads outright. Since you built a separate sub-agent specifically to handle the uploaded file, this is the most likely gap: creating the sub-agent alone does not wire the file to it. If file_upload.mode is "managed" (or missing/defaulting in a way that behaves like it), the sub-agent needs an explicit input binding to @system_variables.uploaded_files or it will never see the file, even though the upload itself succeeded. 

Worth checking: open your Agent Script source and look for a config.file_upload block. If it is absent, add mode: "auto" as the simplest fix so uploads are available agent-wide without extra wiring. If you specifically need per-subagent control, keep "managed" but add the explicit uploaded_files input binding on the file-handling sub-agent's action. 

Docs: Agent Script Blocks, File Upload Sub-Block -

Assumption: I don't have visibility into your actual Agent Script source, so I can't confirm which file_upload mode (or absence of the block) is currently set. This diagnosis is based on the documented behavior of the file_upload sub-block and the fact that a manually created sub-agent needs an explicit uploaded_files binding under "managed" mode.

Hi Wim, you’re correct that the Agentforce interface has changed and Topics may now appear as Subagents in the newer experience.

Please make sure you’re using the Playground/org provided specifically for the Trailhead challenge and that the Experience Management subagent is configured for the CC Service Agent as required by the challenge.

If the challenge still reports that “Experience Management” is missing even though it appears as a subagent and the configuration is correct, please share a screenshot of the CC Service Agent configuration showing the available subagents. If the issue persists, please create a case with Salesforce Support, as this may be related to the challenge checker not recognizing the updated Agentforce configuration.