#TrailblazerCommunity176 discussing

Hola Juan, 

El examen en sí (preguntas del examen) sí está disponible en español (LATAM), así que podés rendirlo directamente en ese idioma sin problema, la traducción del examen la hace Salesforce oficialmente. 

Para preparación, el trailmix oficial de Salesforce es este, y también tiene versión en español (LATAM): 

Un detalle importante: aunque el trailmix esté en español, los desafíos prácticos (hands-on challenges) por ahora solo están traducidos en un grupo limitado de módulos prioritarios (japonés, español LATAM y portugués BR), el resto sigue solo en inglés. Si al hacer un challenge en español te falla la validación, probá cambiando el idioma/región de tu Trailhead Playground a inglés (US) y repetilo con las instrucciones en inglés, a veces la traducción del challenge queda desactualizada respecto al inglés original. 

Sobre la complejidad, la Guía Oficial del Examen (Exam Guide) en Trailhead es el recurso más confiable para saber exactamente qué porcentaje de preguntas corresponde a cada tema (seguridad, automatización, datos, etc.), vale la pena revisarla antes de armar tu plan de estudio. 

Referencia:

Hi @Deepak Sharma, great question. 

In most real-world Salesforce development scenarios, I usually prefer Map<Key, List<T>> when grouping SOQL results because it provides quick access to records based on a key and keeps the code clean and maintainable. 

For example, grouping Contacts by Account: 

Map<Id, List<Contact>> contactsByAccount = new Map<Id, List<Contact>>();  

for (Contact con : [  

    SELECT Id, AccountId, Name  

    FROM Contact  

    WHERE AccountId != null  

]) {  

    if (!contactsByAccount.containsKey(con.AccountId)) {  

        contactsByAccount.put(con.AccountId, new List<Contact>());  

    }  

    contactsByAccount.get(con.AccountId).add(con);  

}  

I would mainly use List<List<T>> when there is no meaningful key and the requirement is more about processing records in ordered groups or chunks, such as splitting records into batches. 

From a governor-limit perspective, the collection type itself is usually not the biggest concern. The important things are SOQL/DML limits, heap size, bulkification, and avoiding SOQL/DML inside loops. 

So my rule of thumb would be: 

• Group and lookup by key ->Map<Key, List<T>> 
• Process ordered chunks/batches -> List<List<T>> 
• Store unique values ->Set<T> 
• Need aggregate/grouped results directly from SOQL -> GROUP BY 

Thanks for bringing up this practical topic. These collection choices make a big difference in keeping Apex code scalable and maintainable. 

@Curtis Hale and @Kundan Kumar Jha  

I had a case in for this issue. Here is the response from Salesforce Support: 

 "Based on our investigation, the current behavior appears to be working as designed following a recent product update. We confirmed that this is not related to user permissions, profiles, or configuration changes in your Salesforce org. 

The update introduced changes to the My Feed experience, including: 

The red “X” previously used to dismiss individual feed items is no longer displayed. 

The Open Count is also no longer shown. 

Users can continue to view and filter their My Feed notifications; however, the option to manually dismiss individual items is no longer available in the updated experience. 

This behavior is consistent across users and has also been observed in other Salesforce orgs following the update. Based on the information currently available, it does not appear to be an org-specific issue or product defect. 

Additional information about the related product changes is available in the Salesforce Release Notes: 

https://help.salesforce.com/s/articleView?id=release-notes.rn_sales_sales_engagement_on_core.htm&release=262&type=5

We understand that the removal of the dismiss option affects how your users manage their daily notifications, and we appreciate you bringing this change to our attention." 

That specific error, 'No assigned org found for the provided email and event code,' almost always means you are going through the sign-up flow again for an org that already exists, rather than just logging into it. A sign-up link / event code is one-time: it provisions the org once and will not re-run, and extending the org's expiration does not re-arm the sign-up link. So the flow you used to create it originally will not work a second time. 

Two things to try: 

1. Do not re-sign-up, log in directly. Go to

(or the org's My Domain URL if you have it) and sign in with the username you created for that LSC org (usually your email with a suffix, and the org has its own password). If you do not remember it, use 'Forgot Your Password' on that login page against the username. The org still exists (it was extended to 2027), so direct login is the path, not the sign-up link. 

2. Confirm you are using the exact email the username is tied to. The error keys on 'email + event code,' so an alias or different-case email will not match. 

If direct login genuinely fails (the username is not recognized at all), then the org may have been unassigned on the backend despite the extension, and re-signup cannot fix that. In that case escalate back through the SAME Partner Support channel that extended it to 2027 (not general Trailhead support), and give them the org Id and the original sign-up/event details, they can see whether the org is still assigned to your Trailblazer account. 

Most likely it is number 1 though, the org is fine and you just need to log in directly instead of re-running sign-up. 

Hope that gets you back in!

Hi @Julie Maris Kemena

Yes, the Personal Best feature has been

If needed, the functionality must now be implemented as a separate, custom LWC card rather than an out-of-the-box setting.