#Permissionset14 人正在讨论

Hi @Yella Vani

As a Salesforce fresher, you don't need expert-level knowledge, but you should have a strong understanding of security concepts with practical examples. 

Focus on these key areas:

1. OWD: Understand Private, Public Read Only, and Public Read/Write with real-time scenarios.
2. Role Hierarchy: Know how record access can be provided to users higher in the hierarchy.
3. Sharing Rules: Understand Owner-Based and Criteria-Based Sharing Rules and when to use them.
4. Profiles: Understand baseline permissions, object access, field-level security, and login restrictions.
5. Permission Sets: Know how to provide additional permissions without changing the user's profile.
6. Practical Scenarios: Practice questions like:
   • Two users have the same profile but see different records. Why?
   • A user can view a record but cannot edit it. What could be the reason?
   • How do you provide record access to another department?

My suggestion: Don't just memorize definitions. Create 3–4 users in a Developer Org and test different security settings.

For fresher interviews, practical understanding and the ability to explain real-world scenarios are more important than advanced concepts.

Hi @ROHIT PIPPERA

As a fresher, you don't need advanced knowledge of Salesforce security, but you should be strong in the basics. 

Focus on these key concepts:

1. OWD: Understand Private, Public Read Only, and Public Read/Write.
2. Role Hierarchy: Know how managers can access their team's records.
3. Sharing Rules: Understand how to provide additional record access.
4. Profiles: Learn about baseline user permissions.
5. Permission Sets: Know how to provide extra permissions without changing profiles.
6. Field-Level Security: Understand how to control field visibility and edit access.

My suggestion:

 Don't just learn definitions. Create a few users in a practice org and test different security scenarios. 

Interviewers may ask why two users with the same profile can see different records or why a user can view a record but cannot edit it.

If you can explain these scenarios confidently, you're well-prepared for fresher-level interviews. 

All the best! 

Thank you, 

Venkat Yadav.

@Rahul Chauhan

, thank you.  I've used validation rules and custom permissions to achieve other rules but I don't think this is a practical solution for this one as we are effectively saying if they try to edit and save any of the fields bar 5 on the opportunity then prevent that.  I don't believe there is a way in a validation to say allow only these 5 fields,  and thererore I would have to list all the fields that they cannot edit - is that correct?  In which case there are too many fields and the managing of this if new fields were added to the opportunity doesn't make it a sensible option.   

I think the only other alternative out of the box would be to have a seperate profile which we were trying to avoid. Do you agree that is the only other option without resorting to apex or such like?

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.