I have a community, added dashboard component to the page and retrieved it. Then when I try to deploy it I receive following error:

Warning unpackaged/experiences/Partner_Portal1 Partner_Portal1 The recordId property of component fdd62e49-579e-4b8c-a678-0efcf9dee728 references an object with the ID value 01Z4M000000oVynUAE. Occasionally, when deployed to a destination org, ID values can become invalid—for example, if the referenced ID doesn’t exist in the destination org. If you encounter component issues in your destination org, verify that the ID values are correct.

I've investigated a bit, when I add dashboard component following changes are made in force-app/main/default/Community/experiences/Partner_Portal1/views/home.json file: "components" : [ { "componentAttributes" : { "height" : "485", "recordId" : "01Z4M000000oVynUAE" }, "componentName" : "forceCommunity:dashboard", "id" : "dd5821dd-f146-41e3-83dc-72f2dfeb15e4", "renditionMap" : { }, "type" : "component" } ],

Does anyone faced with the same problem?

  • Using Daniel Ballinger's handy ID prefix lookup I can confirm that 01Z is the record ID of a dashboard. More than that I cannot help with. As you can see with the other references, these tend to be via generated IDs rather than record IDs to make them portable...
    – Phil W
    May 27, 2021 at 16:13
  • The issue is specifically that there's no dashboard with that ID in the destination org, but I'm not aware of a way to circumvent this error. There are similar errors listed on SFSE but none that I'm seeing specifically related to dashboards. Is deploying without that ID and then setting it to a valid Dashboard ID in your destination (through the Experience Builder) an option?
    – nbrown
    May 27, 2021 at 16:14
  • @nbrown thank for your response, I've tried to deploy without recordId and it throws an error saying "missing required parameter". Also I tried to use "recordId" : "{!recordId}" instead of 01Z4M000000oVynUAE and it gets deployed but no dashboard selected and I need to select it manually later on. My purpose is to deploy community completely with manual steps needed. Thank you May 27, 2021 at 16:28
  • 2
    BTW, if that works it would be a great idea to raise a bug against Salesforce since it really shouldn't be leaving the ID in the retrieved metadata.
    – Phil W
    May 27, 2021 at 16:44
  • 1
    @PhilW thanks for your response, replace recordId with developerName for corresponding dashboard and received an Error force-app/main/default/Community/experiences/Partner_Portal1.site-meta.xml We couldn't validate componentAttributes in Partner_Portal1/views/home.json for component dd5821dd-f146-41e3-83dc-72f2dfeb15e4. Error: attribute [recordId]: CezKsAEFkCPlrQQVBrAcATdTcQtUsL is not a valid value.. Check your file and try again. May 27, 2021 at 16:54

1 Answer 1


Per the inputs from the Salesforce product team, this is working as designed behaviour. This warning was added to alert customers that the dashboardId could become invalid when we are deploying the bundle in a different org where the dashboard corresponding to this id may not be present and hence the component may not work as expected.

Also "The recordId property of component fdd62e49-579e-4b8c-a678-0efcf9dee728 references an object with the ID value 01Z4M000000oVynUAE" is a warning and therefore should not be a blocking error for proceeding with the deployment.

This can be skipped by using "-g" flag when deploying as mentioned in link.

Reference: -g | --ignorewarnings

Optional If a warning occurs and ignoreWarnings is set to true, the success field in DeployMessage is true. When ignoreWarnings is set to false, success is set to false, and the warning is treated like an error.

I do not think this issue should happen when deploying using changesets. Changesets by default ignore any warnings during deployment.And in case of other deployment tools like workbench this flag should be available during deploy as "ignore warnings".

  • 1
    oh... can't believe it's this easy. Literally all of my deployments I have ever done for communities have failed and this could probably have allowed all of them. You should make this more widely known!! Jun 4, 2021 at 22:37
  • 1
    @CasparHarmer Happy to create a Salesforce Knowledge article if this information can help a larger audience. I'll check on this internally and post back. Jun 7, 2021 at 11:18
  • I think a general of topic of how to deploy the new source based communities (and resolve deployment issues) would be a very good topic. Jun 7, 2021 at 18:12
  • 2
    Got this same type of error for a record list component on a page: The filterName property of component 00bf2647-e9b0-4e7f-887d-3ab2ce9cd3bd references an object with the ID value 00B7c000001iBOxEAM. Kind of strange, considering the list view that was created is also in the source and it is on a standard object. Seems like a very bad design that record IDs are being used behind the scenes instead of developer names, by whoever implemented this at Salesforce. Record IDs should never be hard coded. Why aren't developer names used? Jul 22, 2021 at 15:27

You must log in to answer this question.

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