#Trailhead Challenges1.174 discutindo

Thanks Vishal, this was very helpful - you pointed me at the right thing. 

I checked both of your suggestions and here is what I found: 

1) Installed Packages - this was the missing piece. My org (created from the official promo agentforce-for-slack-on-trailhead) has exactly ONE installed package: "Salesforce - Postspin DevOps". There is NO Slack Platform Connector, no Salesforce for Slack, and no Agentforce for Slack package. The Setup tree does expose Platform Tools > Slack (Guided Slack Setup, Manage Slack Connection, Slack Apps Setup, Slack Channels for Records, Specialized Slack Apps), but the backend does not appear to be provisioned, and /lightning/setup/SlackWorkspaces/home renders blank. 

2) Connected Apps OAuth Usage - this part is fine. The Slack app is present, App Status = Allowed, Slack v12.0 in Manage Connected Apps, 4 app actions loaded. 

3) Workspace connection - Approved and Activated, user added and Authenticated, agent installed in the workspace. 

4) I also tried your cached-metadata workaround (switch to another playground, wait 10s, switch back, then check). Same error, so it is not a cache issue on my side. 

So the one thing that seems genuinely missing is the Slack Platform Connector package itself. 

Question: where can I get that package? Is it supposed to be pre-installed in the promo org, or do I need to install it from AppExchange / a specific link? If the promo org is supposed to include it, I can open a Help case saying the promo was provisioned without the connector. 

Thanks again for pointing me in the right direction.

For the date part, Setup > Activity Settings has a "Sort past activities by the completed date" option. With it selected, completed tasks and logged calls sort in the timeline by Completed Date Time instead of due date, so a call that was scheduled in March but only closed in September sorts with September. Events still sort by their start date. On the overdue buildup, the timeline marks any task that isn't complete and has a due date in the past as overdue, so leaving attempts open will always pile up. Closing each attempt, as Vishal suggested, and turning on the completed-date sort means every attempt and the eventual conversation show up on the dates they actually happened. https://help.salesforce.com/s/articleView?id=sales.activitytimeline_sorting_past_activities_task.htm&language=en_US&type=5

I couldn't find that exact message documented, but in this badge the usual miss is the unit's Enable Pricing step: Setup, Salesforce Pricing Setup, Sync Pricing Data, Sync, then wait a few minutes. Checking price book entries alone isn't enough, because Salesforce Pricing reads list prices from a decision table (Price Book Entries V2 in the standard setup). That makes a missing sync my best guess for why repricing fails when you change the quantity. If you already synced, KB 005387253 is worth working through even though it's written for Browse Catalog problems. Refresh Price Book Entries V2 from Lookup Tables, and confirm the pricing procedure and its context definition are active and inside their effective dates. Don't run the sync over and over, since the article warns against syncing several times within an hour. https://help.salesforce.com/s/articleView?id=005387253&language=en_US&type=1

Hi @Saisri Gajula and @Andreea Ionescu

1. Connected org. The checker only inspects the org connected to your Trailhead account. In the Verify Step section at the bottom of the unit, click your Playground name and check that it says it's connected. If you built the template in a different org (a Developer Edition or an older Playground), the checker will never see it. The unit says to connect the org first, so the "Connect Org" step is easy to skip.
2. Same Playground for prerequisites. The unit expects Einstein for Sales to be enabled and the Guest Events tab to exist. The Guest Event object comes from the earlier steps in this path. If you're in a fresh Playground that skipped them, the template can look right but fail validation.
3. Exact template settings.
   • Type: Sales Email
   • Name: Welcome Guest
   • API name: Welcome_Guest
   • Related Object: Guest Event
4. Activation. The error says "active". In Prompt Builder, open the template and make sure a version is Activated, not just saved. A saved draft isn't enough.
5. Prompt body. The unit expects the sender name, phone and email merge fields, plus the check-in welcome instructions, saved in the version you activate.

Practical options if all of that checks out

• Check the expiry. Your screenshot shows the Playground expiring 8 Oct 2026, 5:30 AM IST, which is about two days away. If the checker still fails after you've confirmed the points above, request a new Playground and redo the earlier steps in that one. Creating the template again in a new Playground has worked for some people.
• Open a Trailhead Help case. If it still fails on a clean Playground, report it to Trailhead Help with the screenshot and your Playground details. A validation bug can't be fixed from your side. Replying in the community thread to say you hit the same error also helps surface it.

 I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Hi @Lena Wong

1. Are Public Groups sound as a Flow validation mechanism? 

Why it works: the Flow can read GroupMember, and the groups aren't in sharing rules, so there's no accidental access. 

Why it's fragile: 

• It's an implicit contract. Groups are a sharing construct. Anyone who sees "Group_FieldSales_RegionA" in Setup may reasonably use it in a sharing rule, rename it, merge it, or clean it up as "unused". Nothing in the platform tells them a Flow depends on it.
• The attribute isn't visible where admins work. Nobody looking at a User record or permission set can tell the user is Field Sales.
• Provisioning is manual. Group membership isn't tied to permission set assignments or onboarding automation.

On the "ownership only" argument:

ownership can't distinguish a Field Sales owner from a back-office owner when Profile, Role and groups are identical. You need an explicit attribute somewhere. The real design question is where to store it, not whether to have one. 

2. Better places to store the "Field Sales" attribute   

The

The Permission Sets approach, such as using a Field_Sales_Spain Permission Set with a Custom Permission, requires a Get Records query on PermissionSetAssignment for the account owner. This approach is more auditable, aligns well with access provisioning, and allows the permissions to be bundled into Permission Set Groups. The downside is the additional query, and $Permission only evaluates the running user rather than the Account Owner.

The Public Groups approach, which is the current implementation, works by querying GroupMember. While this approach works with the existing setup, it creates an implicit dependency and uses a sharing-related object to represent a business classification, which makes it less semantically appropriate for identifying sales roles or regions.

If Quotes can be

Gotchas in the current QuoteShare design 

• Manual shares are lost when the Quote's owner changes. If the ERP integration ever updates OwnerId on Quotes, every Flow-created share is wiped. Apex sharing reasons aren't available on standard objects like Quote, so this is a platform limitation.
• Account owner changes need handling. You need a trigger path that removes the old owner's share and adds the new one. Otherwise former owners keep access.
• Region changes need handling too. A change to either the Quote's or the Account's region should recalculate the share.
• ERP loads are bulk. The Flow must be bulkified, with collection based Get Records and no queries inside loops. If volumes are high, an Apex or scheduled reconciliation is safer. I haven't verified your volumes, so check this before settling on Flow.
• Add a reconciliation job (scheduled Flow or Batch) that compares expected and actual QuoteShare rows. Drift is the most common failure in Flow-driven sharing.

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Hi Prema,

If you have completed all the steps but the challenge still shows as incomplete, try the following:

1. Verify that the flow is Activated, not just saved.
2. Ensure all challenge requirements are completed exactly as mentioned in the instructions.
3. Check whether the flow name, scheduled frequency, and actions match the challenge requirements.
4. Click Check Challenge again after refreshing the browser.
5. Log out and log back into your Trailhead Playground.
6. Make sure you're using the correct Playground connected to the challenge.

If the issue persists, please share:

• The challenge name
• A screenshot of your flow configuration
• The exact error message shown when you click "Check Challenge"

This will help identify what's missing and resolve the issue quickly.

Thanks!

Hi Rachel, Producer is the insurance identity, not a junction to the policy. An agent is a Contact with a Producer record (Producer.ContactId). An agency is an Account with its own Producer record (Producer.AccountId). Producer.Type is where you mark them as a partner agent, captive agent, independent agent, and so on. The agent is linked to the agency the normal way: the contact belongs to that account, or you add an Account Contact Relationship. Then each of them has a Producer record on top. State licenses live on Business License. One license can be for a state (Jurisdiction Type = State), with the license class and the line of authority, such as Property or Casualty. An agent licensed in several states gets several Business License records. Which carrier they can sell for is a Distributor Authorization. That is the appointment. It points at the agency account or the agent contact, and it can point at the Business License and at an Authorized Insurance Line. The Authorized Insurance Line is the line the carrier's legal entity is allowed to sell. The authorization is the carrier saying this producer may sell that line. So Producer is not the link between the agent and the policy. The policy relates to the producer separately. Producer is just "this contact or account sells insurance." The clearest write-up past the dev guide is the Trailhead unit Relate Producers, Policies, and Legal Entities, in the Insurance for Financial Services Cloud data model module. Help also has Provide Easy Access to Producer Information, which maps the producer card fields back to Contact, Producer, Business License, and Distributor Authorization.