Question
Does the Metadata API checkOnly flag preserve session state during incremental deployment of small Salesforce applications?
Ash Nea
0 reputation · 26 Jan 2020, 07:19 UTC
147.7K views1
Loading…
0 reputation · 26 Jan 2020, 07:19 UTC
The objective is to evaluate whether Salesforce Metadata API checkOnly flag combined with incremental batch deployment can migrate a small application without interrupting active user sessions. This assessment must account for API version alignment between source and target orgs, and the extent to which dependent metadata types are validated during partial component updates.
Key constraints include potential performance overhead from re‑validating records under concurrent traffic, and the degree to which batch sizing influences session continuity. Uncertainty remains around whether checkOnly previews accurately reflect deployment outcomes when multiple object types, Apex classes, or page layouts are updated sequentially.
Can the checkOnly flag fully validate dependent metadata types before a batch deploy? Which batch size thresholds minimize session disruption while preserving deployment speed? What version‑incompatible metadata types must be excluded or filtered in incremental pushes?
35775 reputation · 26 Jan 2020, 09:11 UTC
No. The Metadata API checkOnly flag does not preserve session state. It validates a deployment package without committing metadata changes, which means it avoids the deploy event that could alter runtime behavior and interrupt active users. Session continuity is a property of what you deploy, not of the validation flag.
With checkOnly=true, Salesforce performs server-side validation of the requested components and may run Apex tests when a test level is set. It does not apply updates to the org. Active users are therefore not exposed to new code, layouts, or object changes during the validation run itself.
Dependency validation is limited to the deployment request and the checks Salesforce performs against current org state. If you split a small application into sequential batches, a passing checkOnly for one batch does not guarantee the next batch will succeed after the first is applied. Include fields, layouts, permission sets, and referenced Apex in the same package when they must be validated together.
No universal batch-size threshold exists in the API contract. Size batches around dependency boundaries and rollback needs rather than a fixed record count. Concurrent traffic can make validation slow or environment-specific, but checkOnly does not add write load that would drop sessions.
Build the package from a retrieve against the target org's supported API version. Exclude or replace metadata types and fields unsupported in the target; mismatches usually appear as unsupported or invalid component errors during validation.
In a sandbox with the target API version, deploy a representative incremental package with checkOnly=true and the same test level you plan to use. Confirm no component changes are applied and record all errors. Repeat with checkOnly=false to compare component status and isolate validation-only behavior from actual deploy effects.
If session drops are reported during a checkOnly run, capture the exact test level and whether Apex tests ran. That detail determines whether you should separate validation from test execution.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
salesforce