Custom Object pages deployed in a Community via the Metadata API will route to the wrong object if the source and target orgs are not in sync
Last updated 2018-05-05 ·Reference W-3928390 ·Reported By 4 users
Custom Object pages deployed in a community (Site.com site or Lightning) via the Metadata API will route to the wrong object if the source and target orgs are not in sync.
This can be a problem for deployment between various environments e.g. sandbox => sandbox, sandbox => production
Reproducible in any org by deploying (Metadata API or changesets) for a Site.com or Lightning community from one org to another:
1. In the source org:
a. Create a custom object e.g. ObjectA
b. Create a basic Napili community e.g. TestCommunity.
c. Create salesforce object pages for the object from #1a.
d. Perform a Metadata API (workbench or ant) retrieve of the sitedotcom community. An example package.xml:
<?xml version="1.0" encoding="UTF-8"?>
2. In the target org:
a. Create a custom object with a different name from the one in #1a (e.g. ObjectB). Create a few records for the purposes of testing the community.
b. Create another custom object with the same name as the one from #1a e.g. ObjectA. Create a few records for the purposes of testing the community.
c. Create a basic Napili community with the same name as the one in #1b e.g. TestCommunity.
d. Deploy the package from #1d to this org via the Metadata API (workbench or ant).
3. Preview the custom object pages and notice that the pages will reference the incorrect object i.e. ObjectB instead of ObjectA.
Other issues can arise due to the reliance on the entity prefix. The object pages may not be visible because an org does not contain a custom object with that entity. When the user attempts to create the pages manually, they may be unable to and received an error that indicates the route already exists.
Until the issue is fixed, to limit occurrences of the problem, a customer can take the following steps:
1. Prior to creating any custom object pages in community builder, create the necessary custom objects in the production org, then refresh the sandbox environments. This will ensure that all objects in each environment are utilizing the same entity prefix. They can then create their custom object pages in builder, where deploying them between the environment should
2. If they create a new custom object or new custom setting in the source org, manually create the same one in the target org at the same time. The object/setting they create in the target org doesn't need to be configurable or accessible to any user apart from the admin. It would essentially be used as a placeholder to ensure the sequence of entity prefixes will be the same in both environments.
3. If they install a managed package that contains custom objects or settings, install the same package in the target org at the same time. Again, users don't need to be permitted access to the package, as the installation is simply to ensure the sequence of entity prefixes is maintained in both environments.
4. Similarly, deleting an object or uninstalling a managed package prior to creating a new custom object can also result in the entity prefixes being out of sync between environments. If they delete a custom object or uninstall a managed package that contains custom objects or custom settings, they should also remove those same objects from the target environment prior to creating the new object.
Is it Fixed?
Any unreleased services, features, statuses, or dates referenced in this or other public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make their purchase decisions based upon features that are currently available.