Loading
These are platform capabilities, so they behave the same way in every product rather than being configured separately in each.
Permissions are a property of the platform rather than a feature of each product. A role granted in Flow behaves identically in Books, and there is one screen to review it — which matters most on the day somebody leaves and you need to be certain access is gone everywhere.
Product access decides which products somebody opens. Record-level scopes decide which rows they see within those products — their team, their region, their accounts. Field-level access decides which columns they see on rows they can already read, which is how a manager approves time without seeing what it costs.
The instinct is that putting everything in one record makes access more dangerous. In practice the opposite is true: seven systems means seven permission models, seven review screens and seven chances to forget one. Concentrating the question makes it answerable.
Most access failures are not sophisticated. Somebody leaves, or changes role, and their access is removed from the systems anybody remembered. One permission model means one action and one confirmation, and the audit trail shows what they could reach up to the moment it was revoked.
The common ones are ownership (records assigned to me), team (records assigned to my reporting line), and region or entity for companies operating across sites. Because scopes read the shared record, 'my team' means the reporting line the personnel file holds today rather than a group somebody maintains by hand.
Yes. Salary is a field-level permission, so approval and compensation are separate grants.
Yes — permission changes are recorded in the same audit trail as data changes.