#Salesforce220 discutindo

Hi Abby, since it works from "View All" but not from the related list, the issue is most likely the related list action rather than your data. From your screenshot, the Choose Price Book window is reappearing, which is a good clue. Things to check: 

1) Open the Quote and confirm the Price Book field is still populated. If the picker keeps showing, the related list may not be reading it. 

2) Check for validation rules or required fields on Quote or Quote Line Item that could be failing without showing an error. 

3) Try an incognito window or another browser, and clear your cache to rule out a cached Lightning component. 

4) If the Quote page uses a Dynamic Related List, re-add the Add Products action or switch back to the standard related list. 

It's also worth searching the Salesforce Known Issues site for "Quote Add Products" in case this came with a recent release. Hope this helps!

@Navarun Halder

, 

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 "

section. 

This will allow you to

from your Trailhead profile. 

Once the exisiting Playground is disconnected, you will see "

" 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.

Hi Guilherme, good questions. Building and testing in a sandbox is the right approach for journeys, segments, content and flows, but treat channel setup as per-org configuration rather than something you deploy. 

1. WhatsApp: The WhatsApp sender is tied to a phone number registered with Meta under a WhatsApp Business Account, and a number can only be active in one place at a time. Use a separate test number (or Meta's test setup) in the sandbox for development and testing, and plan to connect the real business number directly in production. You will repeat the channel connection and template approval steps in production, so document them as a go-live runbook. 

2. Email: Sender domain/subdomain authentication (SPF/DKIM records) is configured per org, so you set it up again in production. For the sandbox, use a dedicated test subdomain so test sends never touch your production sending reputation. IP/domain warming only matters where you send real volume, which is production. Sandbox sends are low volume to internal test addresses, so there is nothing to warm there. 

3. What does deploy: segments, journeys/flows, content and data model changes can move through your normal deployment path (change sets, DevOps Center or a CLI pipeline), but check the current Marketing Cloud Next documentation for which components are supported metadata, as coverage has been changing release to release. 

Tip: build a go-live checklist early that lists every manual production step (WhatsApp number connection, template approvals, domain DNS records, consent/compliance settings, warming plan). DNS changes and Meta approvals can take days, so start them in production in parallel with sandbox testing rather than after sign-off.

Good question, this comes up a lot with Google as the IdP. A few practical options, in the order I would try them: 

1. Let the IdP own MFA. If every user signs in through Google SSO only, enforce phishing-resistant 2-Step Verification in Google Workspace (security keys or passkeys only), then make those users SSO-only in Salesforce (disable login with Salesforce credentials on your My Domain and don't give them direct username/password access). Salesforce's MFA guidance has long treated MFA enforced at the SSO IdP as satisfying the requirement for SSO logins, so the extra passkey registration prompt usually comes from users who can still log in directly or who hold the MFA-for-UI-logins permission. 

2. Check Session Security Levels. In Setup > Session Settings, see which level SAML logins get. If you rely on High Assurance for certain resources, you can move SAML into High Assurance once you trust that Google enforces strong MFA, instead of Salesforce stepping users up after SSO. 

3. If you truly need Salesforce to see the authentication method, put a broker in front. Google currently sends an unspecified AuthnContextClassRef, and I'm not aware of a way to make Google emit a richer ACR/AMR value. Some orgs federate Google through Okta or Entra ID, which can send a meaningful authentication context. That adds complexity, so only do it if option 1 doesn't meet your security team's requirements. 

For the newer phishing-resistant MFA rollout specifically, check the latest Salesforce Help article and release notes on how SSO logins are evaluated, since the details have been changing. 

Common pitfall: when you lock everyone into SSO, keep one or two break-glass admin accounts that can log in directly with a Salesforce-registered security key or passkey, so a Google outage or SAML certificate expiry doesn't lock you out of the org.

Your instinct about the screen flow is right, and it doesn't have to need a developer. 

The core issue is that sharing is all-or-nothing at the record level. Once line B can see a line A Account, it shows up in every report, list view and search. You can't share a record for one screen but hide it in reports. 

So flip the approach: 

1. Remove the sharing rule, so line A Accounts stay private to line A. 

2. Build the screen flow you mentioned, launched from a button on the Opportunity, and set it to run in "System Context Without Sharing". The flow can read the line A record through your lookup and display only the specific fields line B needs. 

3. Show it on the Opportunity page as a screen flow component or quick action, so there are no reports and no broad visibility. 

Watch out: system context also bypasses field-level security. Be deliberate about which fields the flow displays, and document it for your security or audit team (relevant at a firm like yours). 

If line B also needs to report on that information, add a small custom object or a few fields on the Opportunity, filled by a record-triggered flow with a copy of just the fields they need. That gives line B something reportable without opening up the Account.