The partners who pass on the first submission are the ones who treat the review as a quality gate, not a paperwork step. Run the pre-scans, document everything, fix the known anti-patterns, then submit. The partners who fail are the ones who submit and hope.
- Read the AppExchange Security Review requirements end to end
The Partner Security Portal hosts the current requirements document. Read it before writing any code. The requirements update per Salesforce release; old reviews of the requirements miss new policy.
- Run Checkmarx and CheckProduct pre-scans
Pre-scans are available through the Partner Security Portal. Run them on the package, fix every High and Medium finding, document any False Positive with reasoning. Pre-scan clean is the bar for first submission.
- Audit Apex sharing model class by class
Default WITH SHARING. Only use WITHOUT SHARING when the architecture requires it (system-level callbacks, integration users) and document the reason in the class header.
- Audit Lightning components for unsecured data access
Every @AuraEnabled method should have explicit access checks. Components that fetch sensitive data must verify the calling user has appropriate permissions, not rely on the UI to gate access.
- Remove hardcoded credentials and test data
Hardcoded API keys in Apex, test users in custom settings, sample data in static resources. All of these fail review. Use Custom Metadata Types and Named Credentials for configuration; ship sample data through post-install scripts.
- Document every permission set, named credential, and external callout
Documentation is what saves the manual review. For each permission set: what it grants and why. For each named credential: what external system, what authentication, what data flows. For each callout: what payload, what response handling.
- Submit through the Partner Security Portal with all artifacts
Package upload, test org credentials, documentation, listing copy, data processing addendum if applicable. Missing artifacts add weeks to review time.
- Respond to remediation feedback quickly and completely
The remediation report is the roadmap to approval. Address every item; do not pick and choose. Resubmit with a documented response per item. Partial responses extend the cycle.
First submission vs re-submission vs update review. Each has different artifact requirements and timelines.
Checkmarx and CheckProduct findings. Address before submitting to shorten the formal review.
Org credentials the reviewer uses to install and exercise the package. Stage with realistic test data.
Per-permission-set, per-callout, per-named-credential documentation. The largest single factor in first-submission outcome.
Required when the package processes customer data outside Salesforce. Pre-prepare if applicable.
- WITHOUT SHARING used to bypass permission checks (rather than for legitimate system-level reasons) is the single most common cause of failure. Document the reason in every WITHOUT SHARING class header.
- Hardcoded credentials and test data in the package fail review every time. Use Custom Metadata Types and Named Credentials; ship sample data through post-install.
- Incomplete documentation extends review by weeks. Reviewers need to understand every callout, permission, and configuration choice before they can clear it.
- Pre-scans are available and underused. Partners who skip pre-scans fail first submission on issues that the scanners would have caught in an afternoon.
- Every package version after the first requires re-review for security-affecting changes. UI label edits are exempt; new Apex, new callouts, new permissions are not.