1.
1
Svatopluk Sejkora
CzechDreamin
SFDX - Myth Buster
What you need to be careful about

2.
2
CzechDreamin

3.
3
Today’s Items
01 02 03
How to work as an admin on SFDX project Profiles <3 Delta package.xml for Deployment
04 05 06
Anyone changing metadata outside
of agreed process
SFDX metadata specifics Bonus

4.
4
Admin, Scratch Orgs and daily work
It might sound intimidating, to start using console and commands and how the scratch org is
even created.
It is actually very simple, when you work closely within the team!
• Utilize a plugin to make scratch org creation simple (envelope multiple
commands)
► https://www.npmjs.com/package/ci-sfdx-plugin
• Make sure all needed settings are applied and scratch org is ready to use once
created
► You can find basic scratch org setup on the link below
► https://github.com/SvataSejkora/default-scratch-org-template
• Renaming / Deleting items
► Search your repository for any instances, usual suspects:
o Profiles
o Permission Sets
o Translations
o Record Types

5.
5
Profiles
When possible, do not use Profiles to anything besides:
• Page layout assignment
• Default app assignment
• Desktop client access
• Login Hours
• Login IP Ranges
• Session settings
• Password policies
• Delegated authentication
• Organization-Wide Email Addresses
• Default record type per object
• Profile specific search layouts
Reasons:
• To get whole profile you always need to include everything when downloading
metadata
• SFDX pull can’t do it automatically
• In large orgs profiles can have 15K+ lines easily
What to do?
• Go with Permission Sets and Permission Set Groups
• This is going to be future anyways, but using source control is speeding the decision a
lot

6.
6
Package.xml delta
You never want to deploy all your metadata every time
• It increases time to deploy
• It increases potential of error
There are plugins you can use, we are using sfdx-git-delta
https://github.com/scolladon/sfdx-git-delta
It works with GIT and will create package.xml from one commit to second. Usually,
it is used to current HEAD from last successful commit.
Does support generation from between of any 2 commits and can be used for
redeployment of specific items.
Either manual or automatic deployments using this tool are available and picking
one will be based on your project and maturity.

7.
7
Changes outside of expected places
No matter how robust process you have established at your project, there will always be
situations when someone would make changes directly in UAT, Production or any other
restricted environment.
• Required minimum is to obtain information about the changes!
► Although there are options how to handle these situations without any
knowledge, these are not covered in this session.
SFDX has your back covered. You can, quite easily, obtain metadata from any connected
org to your local repository:
• sfdx force:source:retrieve -u connectedOrgName -m
“MetadataType:MetadataName“
► -m “Layout:Account-Account Layout“
► -m “CustomMetadata:MetadataName.MetadataRecordName“
► -m „CustomLabels“
• sfdx force:source:retrieve -u connectedOrgName -p
src/main/default/objects/Lead/
► Will download all items from within given folder

8.
8
SFDX metadata specifics
It would be great to work with all metadata in the same way, but unfortunately it is not possible.
• Custom Labels – always obtain all of them using *, otherwise you will need to merge a lot (fixed in
the latest version)
• Record Types – when pulling, include fields you have modified (fixed in the latest version)
• Workflow Definition – should not be used, not supported anymore
• Search settings – when you delete object you need to delete from here as well. Sometimes you will
get a 0 in “resultPerPageCount” it can’t be zero for push.
• Never include settings you are not using, they can be sources of many errors
• Enabling tracking history for Record Type does not work. There is an error when pushing. Needs to
be enabled manually if needed
• Relate multiple contacts to activities cannot be reliable enabled in scratch orgs (as of May 2022)
• AppMenus – do not include standard one, they cannot be reliable deployed. Also app switcher
cannot be modified via API, so do not include it. Consider always using custom apps for you
projects, and modifying app switcher manually.
• Reports and dashboards – it is fine having them in source but you need to follow proper naming of
your users for sharing (prod username + “.” + sandbox name. For initial scratch creation these names
will be adapted to scratch org user name. This will not work for any subsequent pushes and will
result in failure. Same goes for any user name reference in metadata (queues, flows)

9.
9
How to work with SF features and metadata
You should be careful with your source control content.
You need to have there anything you modified but items you are not using, do not need to be
there. The reason is; they will be there when org or scratch is created as SF is providing
templates, including standard items, for us.
• There are items that you do not want to have in source
► Scratch org related items – they can exist only in production orgs, there is no
advantage of having them (hub, Active Scratch Org)
► Items, you do not use within your implementation (ideas, solutions, knowledge,
work…)
► Always try to minimize number of metadata you have (it influences time of scratch
creation)
• How to enable scratches with
► Knowledge
► Community licenses

10.
10
Any Questions?

11.
11
Thank you! #CD22