The screen shows one datastore as a grid: its fields down the side, your security groups across the top, and an access level in each cell.
Setting levels
Each cell offers inherit, No Access, Read-only or Write. Leaving a cell on inherit means "no rule", which is what keeps an untouched field open to everyone. Set what you need and click Save Field Security.
Saving replaces the whole grid for that datastore, so what you see is always exactly what is in force.
A recommended approach
- Identify the few fields that genuinely need restricting. Resist locking down everything — a large grid is hard to reason about and easy to get wrong.
- Decide the baseline first for each one, usually All Users on Read-only or No Access.
- Then add the specific groups that need more.
- Test with a real account in each affected group, not just as an architect — architect access can mask a mistake.
- Check everywhere the field appears — forms, browse views, custom queries, exports and document templates.
Fields you will not see in the grid
System columns such as the record ID and the deletion marker are excluded, along with hidden, audit and placeholder field types — there is nothing in them for a user to read or write.
If you need to restrict something excluded, look at the level above instead: Permissions for the datastore as a whole, row-level security for which records are visible, Browse Views for which columns a listing shows, or User Input Views for field visibility at each stage of a process.
An important caveat
Hiding a field does not remove what is already in it, and does not retrospectively conceal it from anywhere it has already gone — a report exported last week, a document generated, an e-mail that quoted it. Field Security controls access from now on.