Problem when deploying FlexiPages on Winter '22 org --> "The 'xxxx' component instance doesn't have an identifier specified."

Question

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?

Answer 1

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>

Answer 2

Below is just from me testing this new feature with retrievals/deployments.

The issue in this question will only occur for the following scenario:

1. You have your flexipage metadata in source control as it was in API 52 or retrieve it specifically with API 52 (meaning, no identifier field is in the metadata)
2. You bump your API version to 53 in your deployment commands/pipeline/package.xml

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.

Answer 3

If you're using SFDX and deploying from a repository -

1. Update your sfdx-project.json file to the latest API (as of now- 54.0). Do the same for your package.xml file.
2. Retrieve all flexipage files from Production, assuming that those versions represent what's currently in your source, so that the retrieval will automatically add the <identifier> tags. You can do this simply by right-clicking the flexipages folder 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

**/flexipages/[YourPageName].flexipage-meta.xml

To Exclude an entire Folder (whether the entire metadata type, or a sub-folder) also use that

**/listViews

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.

Answer 4

You might want to downgrade the sourceApiVerison in sfdx-project.json to 52.0

Answer 5

• Upgrade to latest sfdx-cli
• Change api version to 53.0 in sfdx-project.xml
• Change api version to 53.0 in package.xml

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

sfdx hardis:project:fix:v53flexipages

cf https://github.com/forcedotcom/cli/issues/1112#issuecomment-918667726

Answer 6

We just ran into this issue. All I did was run a new Commit on the Flexipage, in the current Source Environment. The 'Instance' lines were automatically added to each 'componentInstance' section. My new deployment was successful.