#Permissionset7 debatiendo

Hi Carolyn - the catch is that RecordType is metadata every user can read, so a Get Records or Record Choice Set on RecordType always returns them all, regardless of who is assigned. There is no native 'filter record types by assignment' in Flow. Two routes that need no Apex you write or maintain: 

1. UnofficialSF's 'User-Aware Record Type Picker for Flows' - a free installable screen component built for exactly this; it shows only the record types the running user is actually assigned. Cleanest option if you are OK installing a component. 

2. Pure-native with Custom Permissions - create one Custom Permission per opportunity record type (or per group), assign each on the same permission set that grants that record type, then set each choice's component visibility (or a Decision) on the running user having that permission via Permission.YourCustomPermission. 100% declarative; the trade-off is you maintain the mapping, so it fits best when the record-type count is small. 

Tip: also run the screen flow in User Mode so field/record access is enforced - just note User Mode will not filter the record-type list itself, since that is assignment, not record access. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

this is a classic Salesforce "Event object permissions" gotcha.

Here’s what’s happening and how to fix it:

Why Debug Works but the Agent Fails

• Debug mode runs as you (the Flow Builder), not the agent. 
  That’s why it works in debug, but fails when the agent runs it.

• The error CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: entity type cannot be inserted: Event means the user doesn’t have permission to create Events.

Why You Don’t See "Event" in Permission Sets

• Events (and Tasks) are controlled by the Activity object, but Salesforce doesn’t show "Activity" in Object Settings in permission sets.
• Instead, Create/Read/Edit/Delete access for Events and Tasks is granted through Profiles or Record Types setup.

How to Give Agents Event Create Access

You have a few options:

1. Profile Level (most common)

1. Go to Setup → Profiles.
2. Open the Service Agent’s Profile.
3. Scroll to Standard Object Permissions.
4. Find Activities → check Create, Read, Edit, Delete (or just Create if that’s all you need).

2. Permission Set (if you don’t want to edit the profile)

• In a Permission Set, you won’t see Activities in the "Object Settings" section.
• Instead:
  1. Edit the Permission Set.
  2. Go to App Permissions.
  3. Under Salesforce CRM, find Activities and Calendar–related permissions (like "Edit Events", "Allow Events").
  4. Assign that permission set to your agents.

3. Check Record Types & Page Layouts

• Make sure the Event record type(s) are assigned to the agent’s profile/perm set.
• If no Event record type is assigned, they won’t be able to create Events even with CRUD access.

The Current Best Practice

Install for System Administrators only, then use Permission Sets (or Permission Set Groups) to grant access to other users. This is the right approach, and here's why:

Why This Model Makes Sense

1. Profiles are becoming baseline containers – They define the minimum floor of access (object CRUD, app visibility, page layouts, record types). The System Administrator profile remains special because Salesforce pushes critical updates to it (like the recent "Manage Connected Apps" permission).
2. Permission Sets layer on top – All incremental access—including app-specific permissions, Apex classes, Visualforce pages, and custom permissions—should be granted via Permission Sets or Permission Set Groups.
3. Admins still need Permission Sets sometimes – As Judi correctly noted, even after installing for Admins, some apps require you to assign their Permission Set(s) to actually use the app. This is intentional: the app may include custom permissions, connected app policies, or field-level security that aren't automatically granted just because you're a System Admin.

What Happens During Installation

When you install an AppExchange package and select "Install for Admins Only":

• Profile-level grants (Apex classes, Visualforce pages, custom tabs) go to the System Administrator profile
• The app's Permission Sets are created but not automatically assigned—you must assign them manually, even to yourself
• Other profiles get nothing unless you explicitly choose them during install

Recommended Pattern

For System Administrators

• Do not clone the standard "System Administrator" profile. Salesforce deploys critical updates only to the standard profile.
• Create a custom Permission Set (e.g., "Acme System Administrator") to grant any additional permissions your admins need beyond the standard profile—new field access, integrations, etc.
• Assign app-specific Permission Sets to admins when needed.

For End Users

• Install apps for Admins only.
• After installation, assign the app's Permission Sets (or build Permission Set Groups) to the appropriate users based on role/function.
• Use Permission Set Groups to bundle related permissions (app access + object permissions + field access) for easier assignment.

Why Profiles Still Exist in the Install Flow

Salesforce hasn't fully deprecated profiles—they're still the required baseline for every user. The install wizard asks for profiles because:

• It needs to grant access to Apex classes, VF pages, and other package components
• Not all packages include Permission Sets (especially older ones)
• The System Administrator profile is the safest default for initial installation

Over time, expect Salesforce to evolve this (possibly auto-creating Permission Sets during install or allowing install without profile selection), but for now, "Install for Admins Only" + Permission Sets is the cleanest, most future-proof approach.

Bottom Line

You're on the right track. The confusion is normal—Salesforce is mid-transition, and the install experience hasn't fully caught up to the permission set model. Stick with:

✅ Install for System Administrator profile only 

✅ Leave the standard System Administrator profile untouched 

✅ Use a custom "System Administrator" Permission Set for any add-on admin permissions 

✅ Assign app Permission Sets manually after install 

✅ Use Permission Set Groups to bundle access for end users

This keeps your org clean, maintainable, and aligned with Salesforce's direction.

@Heath Parks Yes, you should be able to do that. You can get the ID of the MutingPermissionSet using the Tooling API (ensure Tooling API is checked in Salesforce Inspector):

SELECT Id FROM MutingPermissionSet WHERE DeveloperName = 'My_Muting_Permission_Set'

Then use that ID to query FieldPermissions for that MutingPermissionSet (uncheck Tooling API for this):

SELECT SObjectType, Field, PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE ParentId = '0QM000000000000AAA'

To filter to just the Account object, you can filter on SObjectType:

SELECT SobjectType, Field, PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE ParentId = '0QM000000000000AAA'
      AND SObjectType = 'Account'