Suggested answer

I split it deliberately into two categories and treat them differently.

Configuration that is part of the release — a lookup table the new code depends on, a rules matrix, a set of type codes — I model as custom metadata type records wherever the model allows, because those deploy with the metadata. That makes them versioned, reviewable in a pull request and consistent across environments, and it removes an entire class of release-day data loads.

Values that legitimately differ per environment — integration endpoints, feature switches that are off until go-live, credentials-adjacent settings — must be excluded from the deployment payload and set per environment through a documented, repeatable step. Hierarchy custom settings and per-environment custom metadata records are the usual homes. Named credentials handle the endpoint-and-authentication case properly.

The failure I am guarding against is a deployment overwriting a production endpoint with a sandbox one, which is a genuinely bad afternoon. The other is an inventory problem: I keep a version-controlled list of which environment-specific values exist and where they have to be set, without putting the secret values themselves in the repository.

Anything genuinely transactional stays data and is migrated with a data tool, with a plan for external IDs and record relationships.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.