Feed

Good catch, Diego - you are right, thanks for the correction. On a published data source, non-authors cannot impersonate via 'Filter as User', so that test only works for the author editing the source in Tableau Desktop, not on the published copy. 

So for Himshikha the fix stands: grant that user View + Connect on the published data source. To verify the USERNAME() mapping without impersonation, either test it in Tableau Desktop as the source author (where Filter as User is available), or simply drop USERNAME() onto a sheet and have the actual rep open it - whatever value shows must exist in your Territory Owner / entitlement data character-for-character. And if you are on a Virtual Connection data policy, its editor has a 'test as user' preview built in. 

Thanks again Diego :)

There is a solution.

• Define two profiles in the pom.xml file.
• Profile 1: runtime -> for the runtime environment, Profile 2: test -> for MUnit tests.
• Load the JCo dependencies for the runtime profile via Maven and use the maven-shade-plugin.
• For the MUnit tests, the JCo files (sapjco3.jar, sapidoc3.jar, sapjco3.dll, and libsapjco3.so) must be referenced from or downloaded from an artifact repository. They should then be referenced using the attributes <scope>system</scope> and <systemPath>${saplibs}/sapjco3.jar</systemPath>.
• This solution works both locally in Anypoint Studio and on the server side through a CI/CD pipeline.

Hi Carolyn - the catch is that RecordType is metadata every user can read, so a Get Records or Record Choice Set on RecordType always returns them all, regardless of who is assigned. There is no native 'filter record types by assignment' in Flow. Two routes that need no Apex you write or maintain: 

1. UnofficialSF's 'User-Aware Record Type Picker for Flows' - a free installable screen component built for exactly this; it shows only the record types the running user is actually assigned. Cleanest option if you are OK installing a component. 

2. Pure-native with Custom Permissions - create one Custom Permission per opportunity record type (or per group), assign each on the same permission set that grants that record type, then set each choice's component visibility (or a Decision) on the running user having that permission via Permission.YourCustomPermission. 100% declarative; the trade-off is you maintain the mapping, so it fits best when the record-type count is small. 

Tip: also run the screen flow in User Mode so field/record access is enforced - just note User Mode will not filter the record-type list itself, since that is assignment, not record access. 

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

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 :)