#Salesforce Developer486 personnes en discutent

you can still access dev console.  

Hi Deepak - for grouping, Map<Key, List<T>> is almost always the right call. List<List<T>> is rarely right for grouping because you lose the key (no O(1) lookup - you would have to scan to find a group). 

When to prefer each: 

- Map<Key, List<T>>: anytime you group BY something, e.g. Map<Id, List<Contact>> keyed by AccountId. O(1) lookup, keys auto-dedup, and it is the bulkification backbone in triggers. 

- List<List<T>>: only when there is no meaningful key and the split is positional - fixed-size chunks for a callout that takes N records per request, or partitioning work across async jobs. You just iterate the sublists, never look up by key. 

Governor / performance: 

- The limit that actually bites is HEAP (6 MB sync / 12 MB async), driven by how many records you hold in memory, not the collection shape. Map's key overhead is negligible. 

- Map's real win is avoiding nested loops: correlating two lists via a Map is O(n); scanning a List<List<>> to find a group re-introduces O(n-squared). That is the real consideration. 

- Neither changes SOQL/DML limits - those depend on bulkifying, which you do either way. 

Pattern I use for grouping SOQL results: 

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

for (Contact c : [SELECT Id, AccountId FROM Contact]) { 

  if (!byAcct.containsKey(c.AccountId)) byAcct.put(c.AccountId, new List<Contact>()); 

  byAcct.get(c.AccountId).add(c); 

} 

Two more: for a true parent-child group, a subquery like [SELECT Id, (SELECT Id FROM Contacts) FROM Account] groups it at the query level - often cleaner. And for two dimensions, Map<Key1, Map<Key2, List<T>>> stays keyed and O(1). 

Net: default to Map<Key, List<T>> for grouping; reach for List<List<T>> only for keyless chunking. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

Hi @Himanshu Shekhar

,  

Thanks for your response.  

As per the Marketo documentation, whatever objects/fields/system permissions required, we can achieve by creating a permission set and assign that to the integration user.  So, access issue won't be a problem I suppose. I am wondering if anyone knows why Marketo insists the integration user needs to have a FULL Salesforce license? Is there any specific reason behind it? 

Currently, the Barcode Scanner API in LWC (Lightning Web Components) does not provide a built-in option to enable the torch (flashlight) during scanning. While this feature would be useful for scanning in low-light conditions, the API automatically manages the camera settings, and any external torch activation is typically overridden when the scanner starts.

Some developers have attempted workarounds by using the device's camera through WebRTC to enable the torch before launching the scanner. However, this approach is not always reliable because the scanner API may reset the camera settings when activated. As of now, Salesforce has not officially provided a way to keep the torch on while scanning.

If torch functionality is essential for your use case, you may consider submitting a feature request to Salesforce Support for future updates. Just like how customers look for flexibility in dairy queen menu prices canada, users of the Barcode Scanner API are also looking for more control over scanning conditions.