Field-Level Security
Field-level security controls who can see or edit a field independent of the object and page layout it appears on, and it's easy to miss in a deploy.
Definition
Field-level security (FLS) determines whether a profile or permission set can read or edit a specific field, separate from object-level access and separate from whether the field is visible on a given page layout: a field can be readable at the FLS level and still hidden by layout, or fully accessible by FLS and still invisible if a permission set doesn't grant it. Adding a new field to an object doesn't automatically grant any profile or permission set access to it, so a deployment that adds fields without also deploying the accompanying permission set or profile metadata routinely ships fields nobody can see. Apex respects FLS only when code is explicitly written to check it, with WITH SECURITY_ENFORCED, stripInaccessible, or manual checks, so a trigger or class that skips those checks can read or write a field a user shouldn't have access to, a common finding in AppExchange security reviews. Our security review checklist covers FLS as part of a broader audit.
How it works in Serpent
Serpent's org comparison surfaces field-level security drift between sandboxes and production the same way it does for other permission metadata, so a field that shipped without matching access isn't discovered by a support ticket. See org management in Serpent for how permission drift is tracked.

Start free. No credit card, no install, no commitment.
Set up in under 15 minutes. No DevOps hire needed.
