Think in layers: from tightest to widest
Start by deciding the baseline: for each object, what can users see by default? Set the default as restrictive as is practical, then open access where needed. The usual layers are object permissions, which control whether a user can read, create, edit, or delete a type of record; field-level security, which controls individual fields; record access, which controls which specific records a person can see; and sharing mechanisms that extend that access.
- Object permissions: can the user work with this kind of record at all?
- Field security: which fields can they see or change?
- Record access: which individual records are visible to them?
Permissions: profiles, permission sets and groups
Permissions can be granted through profiles and permission sets. A common modern pattern keeps profiles minimal and grants capabilities through permission sets assigned by job function, optionally grouped. This keeps the model understandable: a person's access is the sum of a small number of named sets. Document each set's purpose and owner, avoid one-off sets created for individuals, and review them regularly to prevent drift.
Record access: ownership, roles and sharing rules
Record visibility often follows ownership and the role hierarchy, where managers see their team's records. Sharing rules extend access based on criteria, for example giving a regional team visibility into accounts in that region. Territories, teams, and manual sharing add flexibility. Choose the simplest mechanism that meets the need, since complex sharing slows performance and is hard to explain. Test with real user accounts to confirm that each person sees what you expect.
Managed and advisory services →Sensitive data and additional protections
Identify the fields that deserve extra protection: financial details, personal identifiers, health information, and anything covered by privacy law. Restrict them with field security, consider encryption options for the most sensitive, and monitor access using available event logs. Limit data exports and reports containing sensitive fields to roles that need them. Involve your privacy and security teams in deciding which data classes are stored and how they are protected.
External users and integrations
Portal and partner users need especially tight access, because they are outside your organization. Define exactly which records and fields they can see and test the model with accounts that should see little. Integrations should have their own users with minimal permissions, never a person's credentials. Review integration users regularly, since they often hold broad access that nobody remembers granting.
Experience Cloud for external users →Decisions to settle before you design
- Default access. Set the baseline for each important object, defaulting toward restriction.
- Job-function map. List roles in the business and the capabilities each needs.
- Sensitive data list. Identify the fields that require protection and who may see them.
- Review cycle. Schedule regular access reviews and name who performs them.
A realistic first 90 days
- Days 1 to 30. Inventory current profiles, permission sets, roles, and sharing rules, and identify excess access and sensitive data.
- Days 31 to 60. Design the target model, build it in a test environment, and verify with representative users.
- Days 61 to 90. Roll out in stages, document the model, and run the first access review with managers.
Pitfalls to avoid
- Opening everything to avoid support requests. It solves a nuisance and creates a risk. Grant by need.
- A permission set per person. Individual exceptions multiply and become unmanageable. Group by job function.
- Complex sharing no one understands. If you cannot explain who sees a record, simplify it.
- Forgetting leavers and integration users. Deactivate former staff promptly and review non-human accounts.
