#Trailhead Support30 人がディスカッション中

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. 

@Rahul Mahato

Please log a case in Trailhead for help regarding Superbadges, they can help you better with this. 

•    Super badges are part of the credentialing program, 
• Please make sure you Signed up for a free org with special configuration
• Please check prerequisite.
• If not working, then log the case.  
• Please Check out the Superbadge Challenge Help article (https://trailhead.salesforce.com/help?article=Superbadge-Challenge-Help). 
• To log a case click HERE then  click "Log a Ticket"

Hi Sreemanth — this one is almost always the sharing-settings step on the Inventory objects rather than a problem with your Commerce licenses. Things to try, in order: 

1) Set up the Inventory sharing manually instead of using Retry. Click the "Set up manually" link on the Inventory row, then go to Setup → Sharing Settings → Organization-Wide Defaults → Edit. Set Default Internal Access for Location and Location Group

to Public Read/Write, keep "Grant Access Using Hierarchies" checked, and Save. Sharing recalculation runs asynchronously, so wait for the confirmation email before going back to the assistant. 

2) Don't hit Retry while a sharing recalculation is still running.

If the assistant tries to change org-wide defaults while another recalculation is in flight, the step fails with exactly that generic "We couldn't set up all of the features" message. Wait until it finishes, then Retry so it can continue to steps 4–6. 

3) Check Setup → Deferred Sharing Maintenance and Setup → Background Jobs.

If deferred sharing calculation is suspended in the org, the assistant can't update org-wide defaults at all. 

4) Confirm the Inventory objects are actually provisioned.

Location and Location Group come with Inventory Management / Omnichannel Inventory, and a plain new Developer Edition org isn't always fully provisioned for Commerce. If those objects are missing, spinning up a Commerce-enabled trial org (B2B/B2C Commerce trial signup or Environment Hub) is the fastest route. 

5) Check the running user's permissions.

Make sure whoever runs the assistant has the Commerce Admin permission set plus Modify All Data / Manage Sharing. 

Once Inventory sharing is set manually, the assistant should treat the step as complete and let you finish the rest. If it still sticks at 3 of 6 after recalculation completes, check the Setup Audit Trail around the failure timestamp and raise a support case — the generic message doesn't tell you which object failed, but Support can see it. 

Hope that helps.