Andrew Goodman

Beer drinker. Skier. Salesforce Technical Architect.

[Andrew Goodman @gdmanuk]

@FabienTaillon @rossbelmont @CherFeldman Same. I assumed it was because the principal contains a secret therefore the permission set would be dependent upon something that couldn't be deployed - though I could be completely wrong. After a tonne of faffing with External Creds, I reverted to Legacy Named Credentials.

[Jonathan Pie @JonathanPieNews]

STRIKES!
@RMTunion @theRCN @fbunational
https://t.co/Z2wmYKuCW5

[Andrew Goodman @gdmanuk]

@BobaliciousBob @sfdcJai Yeah, I think that's probably the difference. If you are working with code and straightforward configuration - probably good. If customising the standard clouds with all the weird and wonderful metadata types + profiles - not so much.

[Andrew Goodman @gdmanuk]

@positivepolly06 Yes, one of the worst LC symptoms for me. Has got better over the 2.5 years but does flare up. Try gently massaging your jaw just below your ears. Simple thing that helped me. Only short relief but a lot better than nothing

[Andrew Goodman @gdmanuk]

@Peeps502 Thank you, this is massively helpful! I've been meaning to look into DevOps Center for a while. I was wondering how they were going to solve exactly the issues you raise. Shame that the answer is - they haven't.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Deploy flows as active - the default behaviour in prod is different to sandboxes. SBs get flows deployed as active, prod requires a setting. Go live fails and it takes ages to work out why. SBs shouldn't behave differently to prod. Should be the same or have setting in both.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual A thread, in no particular order of stuff I have to workaround or causes of annoyance...

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Settings files - I generally avoid them as I find nothing but problems with them.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Email deliverability - components are retrieved differently depending on whether email deliverability is enabled. This then means email deliverability must be enabled to deploy those components back. Whether enabled or not shouldn't impact deployment of those components.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Sort order of buttons on layouts - there is a sortOrder tag that controls the order of buttons instead of simply the order of the elements. Adding a new button causes all lines to change. Also ordering changes randomly on retrieve.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Deploying Experience Bundles alongside LWC - haven't checked recently but last I checked, have to split Experience Bundles into separate deployments as the MD API doesn't handle dependencies on LWC/other stuff.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Unpredictable ordering in metadata - some metadata changes order on retrieve between environments or even from same environment. This means lots of noise on retrieve that could be avoided. Examples - lead convert settings, custom app actions, entitlements actions, etc.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual User permissions in profiles - only 'true' entries are retrieved so painful to remove permissions. Must manually create 'false' lines or change in environment. Also, profile support generally in SFDX is lacking. Profiles suck but it'll be a while until we can ignore them.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Deployment of new profiles - if a profile doesn't exist, SF clones from standard profile which already has loads of access. Since profile deployments are additive the new profile has loads of system, user, object, field, etc perms it shouldn't.

[Andrew Goodman @gdmanuk]

@altius_rup @salesforce @SalesforceDevs @rsoesemann @FabienTaillon @aoristdual Luckily twitter limits chars else I could go all night... Top thing for me is the unreliability of SFDX itself, have to throughly test every release before rolling out to our build container. E.g. in the latest release mdapi:deploy does nothing at all - how does that get missed?

[Andrew Goodman @gdmanuk]

@jigarshah189 @aoristdual @msrivastav13 Sorry to be so blunt but this is wrong and would make the bad code worse.

It is to be assumed this code is run from a trigger - should run without/inherit sharing.

With sharing is not something that is done for performance.

Don't need to initialise the list separately.

[Andrew Goodman @gdmanuk]

@aoristdual That's not even going to compile - conList not defined on line 4...

[Andrew Goodman @gdmanuk]

@Nads_P07 I don't know if this is strictly Salesforce support but I'd love to be able to 'trust' https://t.co/Gqc2UyJSaY...

[Andrew Goodman @gdmanuk]

@AidanHarding @Nads_P07 This! I completely agree. IMO all bugs should be logged as issues so we can search, find workarounds and see progress. Doing this would massively cut the number of support calls. There must be so many issues the dev team are not even aware of because it's so painful to raise.