When deploying a FlexiPage to a Winter'22 org I am facing this error:
"The 'xxxx' component instance doesn't have an identifier specified."
How can I fix it?
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.Sign up to join this community
This is a change on the ComponentInstance type. To fix it, add an identifier to your component instance:
<flexiPageRegions> <itemInstances> <componentInstance> <identifier>xxxxId</identifier> <componentName>xxxx</componentName> </componentInstance> </itemInstances> <name>content</name> <type>Region</type> </flexiPageRegions>
Below is just from me testing this new feature with retrievals/deployments.
The issue in this question will only occur for the following scenario:
identifierfield is in the metadata)
You can use/change/interact with a flexipage with no
identifier field and deploy successfully to a Winter '22 org with API 52 or lower in your deployments.
Similar to how other new/changed fields/properties (see example) within the flexipages' metadata have worked before with regards to the latest API, the change should not break any functionality for those who stay on previous API versions.
However, I would recommend retrieving all your flexipages after Winter '22 goes live and committing the version changes so you can be on the latest in terms of your pipeline/deployments. By staying on a lower API, you may risk missing out on being able to deploy the latest features - in this particular scenario, I believe Dynamic Interactions will require you to interact with the flexipage metadata at API 53.
To update your pipeline/deployments/retrievals to use the latest API after Winter '22 (API 53), you will want to retrieve what is currently in production/your org with the latest API (update
sfdx-project.json api version if using sfdx commands) to get the metadata of the flexipages in the latest supported fashion to commit into your source control.
sfdx force:source:retrieve -m FlexiPage
You'll note that
identifier will be there and auto-generated for you for all
componentInstances and incremented appropriately (some examples below):
flexipage_visualforcePage1 force_highlightsPanel1 force_relatedListContainer1 force_relatedListContainer2
You can commit that change to source control immediately after Winter '22 goes live
Below is an example diff from source control pre-Winter '22 compared to that same org with the only change being Winter '22 going live. You'll note that the identifiers are there automatically (I did not set them).
If you don't decide to do the above, you can freely continue to deploy flexipages without this new property assuming you're using API 52 or lower as noted above.
To fix your flexipages, you can either update all your XMLs one by one, or use the following sfdx-hardis command that will automatically do it for you with random identifiers
If you're using SFDX and deploying from a repository -
sfdx-project.jsonfile to the latest API (as of now- 54.0). Do the same for your
<identifier>tags. You can do this simply by right-clicking the
flexipagesfolder and selecting "SFDX: Retrieve Source From Org", or you can run the following terminal command-
sfdx force:source:retrieve -m FlexiPage
Then commit those new versions to your repository, and test by re-deploying your full source to a sandbox. Should resolve everything fairly easily, save for a few possible exceptions depending on your unique situation. For me, we have one Lightning Page that contains Scratch Org objects (we use this for a Developer-related Lightning Page for SFDX training) that will cause validation errors when deploying to non-Dev Hub environments. This is also easy to fix by adding troublesome files and/or metadata types to your
.forceignore file to exclude them from the deployment.
To Exclude a Single File, use the relative path
To Exclude an entire Folder (whether the entire metadata type, or a sub-folder) also use that
Just be careful not to abuse this too much. Only use it when you definitely don't need that metadata to be deployed, or if there truly are exceptions. Do not use this to avoid facing legitimate deployment errors that will catch up with you eventually, and probably in a much less convenient situation.