FAQ-001336 - Package Design and Architecture Security / 2GP Package Structure and Best Practices

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are the best practices for structuring complex applications and multi-package solutions using 2nd-Generation Managed Packaging?
Answer
To structure complex applications and multi-package solutions using 2nd-Generation Managed Packaging (2GP), follow these best practices: **Modular Design and Architecture:** - Break your application into smaller, reusable components and create separate packages for core functionality and additional features - Divide solutions into multiple sub-packages, all tied to a single parent package - Use a base-managed package for core functionality and extension packages for additional features **Namespace and Component Management:** - Share a namespace across packages to ensure consistency and avoid conflicts between components - Use the @namespaceAccessible annotation if classes from one sub-package are used in another to make them accessible within the same namespace (treat this annotation as global) - Ensure each sub-package undergoes its own security review **Versioning and Dependencies:** - Utilize 2GP's versioning capabilities to manage updates and dependencies effectively - Specify package ancestors to inherit listing readiness and streamline the release process - Plan for the application lifecycle with well-defined dependencies between packages - Design updates to the base package to maintain compatibility and not disrupt extension packages **Edition Compatibility:** - Leverage Dynamic Apex to create packages that adapt to different Salesforce editions by dynamically checking for available features - Avoid strongly-typed references to unsupported features in certain editions to prevent installation failures - Support multiple editions and enable upselling by adding advanced features in extension packages **Security and Environment Management:** - Follow security review guidelines ensuring all packages, including extensions, undergo security reviews - Perform data sanitation as close to the sink as possible to maintain security - Utilize the Environment Hub to manage development, testing, and trial environments efficiently - Document dependencies clearly to facilitate maintenance and updates **Planning for Future Growth:** - Design your application to support future growth by considering potential dependencies - Ensure compatibility across packages and plan for scalability - Address vulnerabilities and provide necessary documentation, such as false positive reports, to expedite the review process
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Question
What are the best practices for structuring complex applications and multi-package solutions using 2nd-Generation Managed Packaging?
Recommended Answer Update
To structure complex applications and multi-package solutions using 2nd-Generation Managed Packaging (2GP), follow these best practices: **Modular Design and Architecture:** - Break your application into smaller, reusable components and create separate packages for core functionality and additional features - Divide solutions into multiple sub-packages, all tied to a single parent package - Use a base-managed package for core functionality and extension packages for additional features **Namespace and Component Management:** - Share a namespace across packages to ensure consistency and avoid conflicts between components - Use the @namespaceAccessible annotation if classes from one sub-package are used in another to make them accessible within the same namespace (treat this annotation as global) - Ensure each sub-package undergoes its own security review **Versioning and Dependencies:** - Utilize 2GP's versioning capabilities to manage updates and dependencies effectively - Specify package ancestors to inherit listing readiness and streamline the release process - Plan for the application lifecycle with well-defined dependencies between packages - Design updates to the base package to maintain compatibility and not disrupt extension packages **Edition Compatibility:** - Leverage Dynamic Apex to create packages that adapt to different Salesforce editions by dynamically checking for available features - Avoid strongly-typed references to unsupported features in certain editions to prevent installation failures - Support multiple editions and enable upselling by adding advanced features in extension packages **Security and Environment Management:** - Follow security review guidelines ensuring all packages, including extensions, undergo security reviews - Perform data sanitation as close to the sink as possible to maintain security - Utilize the Environment Hub to manage development, testing, and trial environments efficiently - Document dependencies clearly to facilitate maintenance and updates **Planning for Future Growth:** - Design your application to support future growth by considering potential dependencies - Ensure compatibility across packages and plan for scalability - Address vulnerabilities and provide necessary documentation, such as false positive reports, to expedite the review process
Reasoning
The FAQ content is accurate and comprehensive for 2GP package structuring and best practices. No outdated content was detected, and the information aligns with current Salesforce 2GP guidance. The content is well-organized and covers the essential aspects of multi-package solutions including modular design, namespace management, versioning, edition compatibility, security considerations, and planning for growth. No security rules were selected because this FAQ focuses on architectural and structural best practices for 2GP packaging rather than specific security implementation details. While the FAQ mentions security considerations (like ensuring each sub-package undergoes security review and data sanitation), it doesn't contain specific technical implementations that would trigger the available security scanner rules. The security rules in the provided list are primarily focused on code-level security issues (SOQL injection, XSS, CRUD violations, etc.) rather than high-level package architecture decisions.