21

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?

Improve this question

6 Answers 6

Reset to default
19

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>
Improve this answer
7
  • 7
    This is a breaking change by SF in that case, with no backwards compatibility, which is a very bad thing for them to do. Will this be corrected before Winter 22 GA? In addition, is this likely to impact managed packages that contain flexipages with no identifiers?
    – Phil W
    Commented Sep 9, 2021 at 8:37
  • 2
    Hey Alba, that's a PM that has no care about the number of developers who will be impacted. This sort of breaking change, though minor, will cost each developer time, wasting potentially years of "man time" across the entire developer base.
    – Phil W
    Commented Sep 10, 2021 at 15:11
  • 2
    Thank you Phil for your feedback. The suggested workaround is: 1- Retrieve the same page using the newer API version which would generate the required identifiers for them 2 - Use this metadata to deploy using the newer API version
    – Alba Rivas
    Commented Sep 10, 2021 at 17:13
  • 2
    You can save some time with a RegEx search and replace: twitter.com/PhilippeOzil/status/1443938580380913671
    – POZ
    Commented Oct 1, 2021 at 14:00
  • 4
    Completely agree with @PhilW point. Moreover, changes that break backward compatibility should be communicated in advance (at least that what serious products are doing), so that devs can get ready by analyzing code base, preparing changes etc. It's by far not OK that we are getting to know about this error only after encounter it in practice and figuring out solution in stack overflow post(
    – wesaw
    Commented Oct 21, 2021 at 8:53
10

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

enter image description here

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.

Improve this 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.

Improve this answer
2

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

Improve this answer
1
  • 1
    Welcome to the site Ben - as it stands this got auto flagged for being low quality by the system, mostly because of the short length. When there's a lot of existing answers with more detail you'll rarely get an up-vote for an answer like this. Please do stick around though! :)
    – Matt Lacey ♦
    Commented Mar 22, 2022 at 14:37
1
  • 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

Improve this answer
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .