Feed

Hi , 

Salesforce Support has confirmed that this is a known issue.  

Workaround to complete the challenge

: Creating a new Org again from scratch and repeating the steps fixed the issue.   

To create a new Org using the button " 

Create Playground" on the unit, you should create a normal Playground from Profile > Hands-On Orgs

section.  

This will allow you to 

Disconnect existing Einstein AI Playground

from your Trailhead profile.  

Once the exisiting Playground is disconnected, you will see " 

Create Playground

" button on the unit once again, you can use the same to initiate the creation of new Einstein AI Playground and repeat the steps.  

This has worked for me & I was able to complete the badge.   

https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007ifh14 

Hi Luis, thanks for the screenshot, it shows two likely causes: 

1) Your Opportunity organization-wide default is Public Read/Write. Sharing rules can only open access beyond the default, so with Public Read/Write the rule has nothing to share and the checker can't confirm it. Set Opportunity's default internal access to Private (as the earlier step asks), and let the recalculation finish. 

2) The rule's criteria use Won equals True. Edit the rule and use the criteria exactly as written in the unit (Stage equals Closed Won), and set the access level the instructions specify. Keep the rule name exactly 'Share Won Opportunities with Account Receivable' and Share With = Roles: Accounts Receivable. 

After saving, wait for the sharing recalculation email (or check Background Jobs) before you click Check Challenge. Hope this helps!

こんにちは。商談の履歴トレンドは次の手順で有効化できます。 

1) 設定のクイック検索で「履歴トレンド」を開き、オブジェクト一覧から「商談」を選択します。 

2) 画面上部の「履歴トレンドの有効化」にチェックを入れます。これが機能自体のオン／オフで、事前準備として必要なのはこのチェックです。 

3) 下の「項目の選択」は、どの項目の変更履歴をトレンドデータとして保存するかを決める設定です。チェックした項目だけが「履歴トレンド」レポートで過去の値と比較できます。特に必要がなければ、初期状態のままで問題ありません。 

4) 保存したら、レコードクローンのインストールを再度試してください。 

履歴トレンドを有効にしても既存のデータやレイアウトは変わらないので、安心して設定して大丈夫です。ご参考になれば幸いです。

Hi Ellen, this checker reads the deployed augmentor.html in your org, so it's usually either the markup or the deploy. Things to check: 

1) In augmentor.html, the child tag should pass the value as an attribute, like this: <c-numerator counter={startCounter}></c-numerator>. The attribute must be all lowercase (counter), with no quotes around the curly braces. 

2) In numerator.js, counter must be a public property, declared with the api decorator and with api imported from lwc. 

3) Right-click the augmentor folder in VS Code and choose SFDX: Deploy This Source to Org, and confirm there are no deploy errors. A local edit that wasn't deployed is the most common cause. 

4) Make sure the org your VS Code project is authorized to is the same org selected in the challenge dropdown. 

Hope this gets you past it!

Hi Christine, the error points to the old API version. Code saved on v25 can't see field types that were added to the platform later, and custom Address fields are one of them, so when OppSyncTrigger touches Opportunity.address__c it fails with "inaccessible in this context". Because QuoteSync is a managed package, you can't change the trigger's API version yourself. 

Options, from quickest to most durable: 

1) Remove address__c from the QuoteSync field mapping (and from the matching Quote mapping) so the package no longer queries it. That should stop the error right away. 

2) If you need that address synced, copy it with a small record-triggered Flow on Quote/Opportunity instead of through the package. 

3) Longer term, plan to replace QuoteSync. It's an old Labs package with no recent updates, and native Quote syncing plus a Flow (or a small Apex trigger on a current API version) for custom fields is easier to maintain through future releases. 

Test any change in a sandbox first, since the trigger runs on every Opportunity update. Hope this helps!

Hi, this error means the checker can't find a topic with that exact name on the agent it's checking. A few things that usually fix it: 

1) Open the Sales Coach agent in Agentforce Builder and confirm the topic is named exactly Opportunity Coaching (same spelling and capitalization, no extra spaces) and that its API name wasn't changed. 

2) Make sure the topic is added to the agent itself, not only saved in the Topics library. 

3) Deactivate the agent, save the changes, then activate it again. The checker reads the active version. 

4) Confirm the org selected in the challenge dropdown is the one you configured. 

If all of that matches and it still fails, open a case with Trailhead Help with a screenshot of the agent's topic list. Hope this helps!

Hi Shubham, those errors mean the action's input/output schema is empty, so Agentforce Builder isn't seeing your flow variables. That usually happens when the action was created before the flow version with those variables was saved and activated, and the action keeps the old schema. Try this: 

1) In Flow Builder, open each flow and confirm the active version has the variables marked Available for Input/Output, with API names exactly email, memberNumber, experienceName, contact, experienceRecord. 

2) In Agentforce Builder, delete the two custom actions, refresh the page, and create them again from the flows. The inputs and outputs should now fill in automatically. 

3) Only after they appear, set Require Input and Show in conversation. Don't add a complex data type to the text inputs; that's only for record/object types. 

4) Save, then commit or activate the agent version before checking the challenge. 

Hope this helps!

Hi Shreya, your trigger logic is fine. "Failed to enqueue tests: An unknown exception occurred" is an org-side error when the checker tries to run tests, not a problem with your code. Things that usually clear it: 

1) Go to Setup > Apex Classes and click "Compile all classes". One broken class anywhere in the org can stop tests from queueing. 

2) Check Setup > Apex Test Execution. If any test runs are stuck in the queue, abort them, wait a few minutes, then check the challenge again. 

3) Make sure the trigger is Active and the Match_Billing_Address__c checkbox field exists with exactly that API name. 

4) Optional: the challenge only asks you to copy the postal code when the checkbox is true, so you can drop the null check to match the spec exactly. 

If it still fails, deploy the same trigger to a fresh playground. That error is often a temporary playground issue. Hope this helps!

Hi Manav, there's no published mapping for those CORE.USERS.* tokens, but you can get both pieces from the platform instead of hard-coding them: 

1) Eligible columns: call the REST List Views describe endpoint on an existing User list view (/sobjects/User/listviews/{listViewId}/describe). Each column comes back with fieldNameOrPath (the normal field API name) and selectListItem, and the sortable/filterable flags tell you what the UI allows. 

2) Token mapping: as a one-time step, create a User list view in the UI with every column you want to support, retrieve it with the Metadata API, and compare its <columns> with the describe output. Store that as a small mapping (custom metadata works well). Custom fields like DVC_Is_Manually_Cleared__c keep their normal API name, so only standard fields need mapping. 

3) For filters, use Schema describe (DescribeFieldResult.isFilterable()) to remove fields that can't be filtered before showing them in your LWC. 

Also, since you're using a Named Credential for Metadata API calls, check that the integration user's permissions don't let end users create list views beyond what you intend. Hope this helps!

Hi Marcel, both are solid, but they come from different angles, so it depends on how you use DemandTools today. 

DataGroomr is cloud-based and uses machine learning to suggest duplicates, so there's less matching-rule setup. It's a good fit if dedupe and merge are your main use. 

DemandTools is broader. If you rely on mass modules like bulk reassign, standardize, import with dedupe, or complex master-record rules, check that DataGroomr covers each one before you switch. 

How I'd evaluate it: 

1) List the DemandTools jobs you actually run each month. That list is your requirements. 

2) Run a trial on a full sandbox and compare the duplicate sets, merge results (which values survive), and scheduled job options. 

3) Price it against your record volume and number of users, and include Plauti Duplicate Check or Cloudingo in the comparison for negotiating leverage. 

Also turn on native Duplicate and Matching Rules to block new duplicates at entry. That lowers how much cleanup any tool has to do.