#Trailhead609 discussing

Hey Seenu, 

Good point, thanks for adding that. If Trailhead is showing a platform-side banner about active playground/assessment issues, that would explain why the troubleshooting steps above haven't resolved it for some people, it may just be a temporary backend issue on Trailhead's side rather than something fixable client-side. Worth keeping an eye on that banner and retrying once it clears.

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. 

Hi Dan - the app is Trail Tracker (Salesforce Labs, free on AppExchange). It syncs each user's earned + in-progress badges, points and trailmixes daily via an API integration user, lets you ASSIGN badges/trailmixes, and ships with pre-built reports and dashboards. So 'how many badges/points a user earned' and assigning learning are covered out of the box. 

The specific things you listed are NOT native, though: 

- Available points per badge (earned vs available): it syncs what's earned, not a catalogue of available points - you'd maintain that reference yourself. 

- Alerts when a completed badge is revised or gets new content: no mechanism. Trailhead doesn't surface 'this badge changed' through the sync. 

- Certifications: not synced. Certs aren't badges (they live in a separate system), so it won't pull them - track those manually or via a separate integration. 

- Quests: not a standard synced object either (quests are temporary badge campaigns). 

The upside: Trail Tracker is a Labs app, so you get the objects and code - you can extend it (custom fields for available points, a flow to flag changes, a custom object for certs) rather than build from scratch. Out of the box, though, it's badge/points/trailmix tracking + assignment, not the full picture you're after. 

If this helps, please mark it as the Best Answer so it points the next person the right way - 🙂