Role-Based Access Control (Profiles & Permission Sets)

GoldFinch runs on the Salesforce platform, which provides role-based access control out of the box through Profiles and Permission Sets. This article explains how access is structured, how visibility is layered on top of it, and what your team should plan for during implementation.

How access is controlled

Two mechanisms work together to determine what a user can do and see:

• Profiles and Permission Sets control application, object, field, and system permissions — essentially, what a user is allowed to do (create, read, edit, delete, approve, post, administer, export, and so on).
• Organization-wide defaults, roles, sharing rules, and teams determine record visibility — which specific records a user can see, independent of what actions they're permitted to take.

A user's overall access combines both layers: permission (via Profile/Permission Set) and visibility (via role, sharing, and org-wide defaults).

Least-privilege by default

GoldFinch follows a deny-by-default model: Profiles and Permission Sets are configured to grant only the minimum functions required for each role, rather than granting broad access and restricting afterward. This applies whether a role needs full transactional access or read-only visibility — read-only users can be prevented from creating, editing, deleting, approving, posting, or administering data. Review report and export permissions separately from read access, since the ability to view a record does not automatically imply the ability to extract or export that data.

Segregation of duties

Permission Sets, roles, sharing, and approval steps can be combined to segregate critical functions — for example, separating who can request, approve, receive, adjust, pay, post, and administer within inventory or financial workflows. This is a configuration and governance exercise, not a fixed setting: your organization should define and approve a segregation-of-duties matrix, then test both the access combinations that should be permitted and the ones that should be blocked.

Role-specific landing pages

You can assign default landing pages and apps per Profile or Permission Set, so different roles land on different home experiences—for example, a warehouse-floor view for pickers, a different view for volunteers, and another for procurement staff.

Privileged accounts

Privileged permissions (such as "Modify All Data" or delegated admin rights) can bypass ordinary sharing controls by design, so they need their own set of precautions. Recommended practices include:

• Minimizing the number of privileged accounts
• Separating administrative identities from daily-use accounts
• Requiring strong MFA or SSO for privileged access
• Using delegated administration where practical, instead of full admin rights
• Restricting login context (e.g., IP ranges, login hours)
• Monitoring privileged activity and performing periodic access reviews

All administrative and configuration changes are automatically captured in the Setup Audit Trail, giving you a record independent of the access review process itself.

Quick reference

Related reading

• Single Sign-On Setup (SAML / OpenID / Microsoft Entra ID)
• Audit Trails & Field History Tracking Setup
• Password Policies & Login Lockout Configuration