With the release of the new Nonprofit Cloud, Salesforce has moved toward a "Permission Set-led" security model. This means that instead of relying on a few complex Profiles, Admins use Permission Set Groups to bundle various functional permissions (like Fundraising, Case Management, and Grantmaking).

In many scenarios, a consultant might find that a standard, "out-of-the-box" permission set provided by Salesforce grants a wide range of permissions (Create, Read, Edit, and Delete). If a specific group of users—such as interns or board members—needs to see that data but should not be allowed to change or delete it, the Administrator uses a Muting Permission Set.

How to Implement Muting:

Create a Permission Set Group: The Admin creates a group called "Read-Only Fundraising Staff."

Add the Standard Permission Set: The Admin adds the standard Fundraising Access permission set to the group. This initially grants full access.

Add a Muting Permission Set: Within that same group, the Admin clicks "Muting Permission Set in Group" and creates a new one.

Configure Muting: In the Muting Permission Set, the Admin navigates to the Object Settings for objects like Gift Commitment or Individual Application (Grantmaking). They check the "Muted" box for Create, Edit, and Delete.

Assign the Group: When the group is assigned to users, the system calculates the "Final Effective Permissions" by taking the standard permissions and "muting" the ones specified. The result is a clean, read-only experience.

Why other options are incorrect:

Restriction Rules (Option A) are used to limit which records a user can see based on specific criteria, not to change the level of access (Read vs. Edit) for an entire object.

Sharing Rules (Option B) are used to open up access to records, not to limit the functional ability to Edit or Delete once a record is already visible.