What problem does it solve? Liferay portlet preferences that store raw numeric primary keys (groupId, structureId, folderId) break silently after Site Initializer imports, Staging publishes, or LAR imports, because auto-incremented IDs differ across instances. This Skill provides the rule and proven fix recipes for storing externalReferenceCode (ERC) instead. ## Core Features & Use Cases - Design rule for widget configuration: Any portlet preference referencing another Liferay entity (site, DDM structure, file entry type, folder, object definition) must persist the ERC, resolving to the numeric ID only at the point of use. - Proven fix recipes: Documents the completed definitionId → definitionERC migration (with a DefinitionResolver OSGi service and request-scoped caching) and the rootFolderId → rootFolderERC migration (with a bidirectional FolderResolver dispatching across DLFolder, JournalFolder, and KBFolder, plus ERC-based breadcrumb URL tokens). - Code review checklist: Flags known violations such as the still-unfixed subTypeId preference and explains why displayStyleGroupId follows Liferay's own key/ERC pattern and should not be blindly rewritten. - Use Case: When reviewing a *PortletPreferences class or a page-definition.json that configures search portlets, apply this Skill to detect raw-ID storage and follow the resolver-service pattern to make the configuration survive re-imports. ## Quick Start Review this portlet preference that stores a folder ID and refactor it to store and resolve an externalReferenceCode instead.