LET'S LEARN TOGETHER. THE BEAUTIFUL THING ABOUT LEARNING IS NOBODY CAN TAKE IT AWAY FROM YOU.

Understand Field's Visibility with Field-Level Security and Page Layout


We all know that Field-Level security (FLS) and Page Layout are very important concept. But let us understand the concept with multiple use cases. I always believe going through use cases/scenarios are the best way to learn the concept.

Use Case 1:
Object Name: Student
Field Name: Student Name
Field is required: Yes

Let’s try to change the field’s security both in profile level as well as through page layout.

Changing though Field Level Security @ Profile Level (say for profile: Sales User) –
You can’t change Field Level Security for a field if the field is marked as required during declaration. The field will become visible for all the profiles as shown below -
So is it possible to do something in page layout? Let’s check –
Seems like here also you can’t do any changes. Below is the screenshot –
So the conclusion is that if a field is marked as required during declaration, that field will remain required and visible in all the page layouts. You can’t make that field read-only also.

Use Case 2:
Object Name: Student
Field Name: Student Age
Field is required: No
Now we can have multiple scenarios. They are listed below –
Scenario 1:
Visible for Profile – Sales User: No
Visible for Profile – Executive User: Yes
Required in Page Layout - Yes
Observation:
Logged in as Adams, Karen (Profile – Sales User)
Logged in as Bassi, Brent (Profile – Executive User)

Scenario 2:
Visible for Profile – Sales User: Yes
Read Only for Profile - Sales User: Yes
Required in Page Layout - Yes

Observation:
Logged in as Adams, Karen (Profile – Sales User)
Scenario 3:
Visible for Profile – Sales User: Yes
Read Only for Profile - Sales User: No
Required in Page Layout - Yes
Observation:
Logged in as Adams, Karen (Profile – Sales User)

Scenario 4:
Visible for Profile – Sales User: Yes
Read Only for Profile - Sales User: No
Required in Page Layout - No
Read Only in Page Layout - Yes

Observation:
Logged in as Adams, Karen (Profile – Sales User)
Use Case 3:
Object Name: Student
Field Name: Student Age
Field is required: No
Visible for Profile – Sales User: No
Validation Rule in Student Object: 


Observation:
Logged in as Adams, Karen (Profile – Sales User)
So the conclusion is that validation rule still applies even if the field is set to not visible.

Hope now you can get better understanding of the how Field-Level Security and Page Layout works together. Any feedback, please let me know. Thanks.





Share:

1 comment:

Follow Me

Enter your email address:

Delivered by FeedBurner

Popular Posts

Labels

Salesforce (105) Apex (45) admin (27) visualforce (21) ADM (20) dev 501 (19) integration (18) learn salesforce (18) 501 (16) SOAP (13) lightning (12) tutorial (11) Certification. (9) javascript (9) Trigger (7) test class (7) unit testing (7) Advanced Admin (6) Certification (6) Sharing and Visibility (6) design pattern (6) developer (6) report (6) salesforce release (6) security (6) trailhead (6) Kitchener Developer Group (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) formula (5) mobile (5) service cloud (5) solution management (5) use case (5) Advanced Apex (4) JSON (4) Lightning Experience (4) Salesforce DX (4) WebSphere (4) best practice (4) cast iron (4) component (4) deployment (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) Architect (3) Live Chat (3) Online Event (3) Opportunity (3) Performance (3) Products (3) REST (3) Role (3) Sales Cloud (3) Scratch Org (3) Study Notes. (3) Summer15 (3) Tips (3) Web Technology (3) dynamic apex (3) event (3) license (3) map (3) mapbox (3) singleton (3) version controlling (3) Bulkify (2) Data Architecture and Management Certification (2) Devops (2) Distributed Version Controlling (2) ES6 (2) Eclipse (2) Einstein (2) Enterprise Territory Management (2) Financial Services Cloud (2) Force.com IDE (2) Governor Limit (2) Groups (2) IBM (2) Implicit Sharing (2) JourneyToCTA (2) Kitchener User Group (2) Lightning Design System (2) Live Agent (2) Metadata (2) Price Book (2) SOSL (2) Sharing (2) Spring 15 (2) Summer17 (2) Territory (2) ant (2) automation tool (2) basic (2) chatter (2) coding (2) communication (2) console (2) controller (2) documentation (2) flow (2) git (2) jquery (2) logging (2) object (2) permission (2) process builder (2) release (2) salesforce1 (2) strategy (2) xml (2) Action Plan (1) Action Plan Template (1) Advanced Currency (1) Agent Productivity (1) Analytics (1) Apex Sharing (1) Arrow (1) Asynchronous callout (1) Aura Framework (1) Bots (1) Browser (1) Bulk data load (1) CTA (1) Calendar (1) Canon (1) Case Management (1) Celebration (1) Cheat Sheet (1) Classic (1) Community (1) Confetti (1) Constructor (1) Contact Center (1) Continuation (1) Continuous Integration (1) Convert (1) Cookie (1) Custom Metadata (1) Custom Object (1) Customer (1) Dated Exchange Rate (1) Decorator Design Pattern (1) Dev Hub (1) Diwali (1) Email (1) FSC (1) Function (1) Goals (1) Guide (1) Household (1) Ideas (1) Improvement (1) KPIs (1) Large Data Volume (1) LastModifiedDate (1) Lightning Web Component (1) Manage Currencies (1) Manual Sharing (1) Metrics (1) Multi Currency (1) New (1) New Feature (1) OOPS (1) OWD (1) Omni-Channel (1) PD II (1) Partner (1) Person Account (1) Photo (1) Pipeline (1) Platform Developer I (1) Presentation (1) Product Schedule (1) Profile (1) Promise (1) Prototype (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Retrieve (1) Role Hierarchy (1) SFDX (1) Salesforce Optimizer (1) Session (1) Sharing Rule (1) Sharing Sets (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) Summer19 (1) Switch (1) SystemModStamp (1) User License (1) Users (1) Webservice (1) Winter'15 (1) Winter'17 (1) access (1) actionFunction (1) actionPoller (1) actionRegion (1) actionSupport (1) agile (1) app (1) approval process (1) aura (1) awesome (1) backup (1) bitbucket (1) book (1) campaign (1) change set (1) code (1) code coverage (1) configuration (1) csv (1) custom button (1) custom settings (1) customization (1) data loader (1) database (1) delegate Admin (1) describe (1) dom (1) dreamforce (1) duplicate (1) dynamic (1) equals (1) error (1) field-level security (1) folder (1) ftp (1) generic (1) gift (1) global describe (1) hashcode (1) import wizard (1) jenkins (1) keynote (1) long running requests (1) monitoring (1) mysql (1) page layout (1) personal (1) power of one (1) record type (1) relationship (1) request (1) review (1) sub-tab (1) tab (1) username (1) visual workflow (1) workflow (1)

Blog Archive

Total Subscribers

Total Pageviews