I have a specific field on a custom object that I need to update but am not able to edit it. I've tried multiple ways including on the page, using data loader & the developer console. I am able to update other fields on the object without any problems. For my user profile, the field level security is set to visible and not read-only. The field permissions on the object settings are set to Read and Edit access. For the only permission set applicable, the field permissions on the object settings are set to Read and Edit access. The field is not set to Read-Only on page layout. The field is set to required though.
Hi Joe, this is a frustrating one because everything you listed checks out individually.
Two things worth checking that don't show up in the usual places:
Permission set groups. If the applicable permission set is inside a group, the group can apply muting that silently overrides a field permission the individual permission set grants. You'd see Edit on the permission set itself and still lose it at the group level, and there's no single screen that shows you the combined result.
Multiple permission sets stacking. If more than one permission set applies to you and any of them explicitly restricts that field, it can take precedence depending on how they combine. Worth listing every permission set assigned to your user, not just "the only one applicable" you checked, since a second one might exist without being obvious from your own profile view.
Also double check it isn't a formula or rollup field, since those ignore FLS edit settings entirely and are never editable regardless of permissions. And if it's a lookup or master-detail, the parent record's sharing settings can block the edit even when every permission you listed is correct.
Disclosure: I'm at TwinStack, and this exact problem, being unable to see the combined effect of profile plus every permission set plus groups plus sharing in one place, is what we built Who Sees What for. It's a free AppExchange app that resolves a user's full access, object, field, and record level, in one lookup and names the specific rule responsible for each grant, rather than making you reconstruct it by checking each source separately.
Not sure if this thread is still live for you three years on, but if anyone else lands here with the same problem, checking permission set groups specifically is the one people miss most often.