A blog dedicated to Salesforce Ohana

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 (101) Apex (43) admin (27) ADM (20) visualforce (20) dev 501 (19) integration (18) learn salesforce (18) 501 (16) SOAP (13) tutorial (11) Certification. (9) lightning (8) Trigger (7) test class (7) unit testing (7) design pattern (6) report (6) security (6) trailhead (6) Advanced Admin (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) developer (5) formula (5) javascript (5) mobile (5) salesforce release (5) service cloud (5) solution management (5) use case (5) JSON (4) Lightning Experience (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) Advanced Apex (3) Certification (3) Live Chat (3) Performance (3) Products (3) Sales Cloud (3) Study Notes. (3) Summer15 (3) Tips (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) Distributed Version Controlling (2) Eclipse (2) Einstein (2) Financial Services Cloud (2) Force.com IDE (2) Governor Limit (2) IBM (2) Kitchener Developer Group (2) Lightning Design System (2) Live Agent (2) Metadata (2) Online Event (2) Opportunity (2) Price Book (2) REST (2) SOSL (2) Salesforce DX (2) Scratch Org (2) Spring 15 (2) Summer17 (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) permission (2) process builder (2) release (2) salesforce1 (2) strategy (2) xml (2) Action Plan (1) Action Plan Template (1) Agent Productivity (1) Analytics (1) Architect (1) Asynchronous callout (1) Bots (1) Browser (1) Bulk data load (1) CTA (1) Calendar (1) Canon (1) Case Management (1) Classic (1) Contact Center (1) Continuation (1) Continuous Integration (1) Convert (1) Cookie (1) Custom Metadata (1) Custom Object (1) Decorator Design Pattern (1) Diwali (1) Email (1) Enterprise Territory Management (1) FSC (1) Goals (1) Groups (1) Guide (1) Household (1) Ideas (1) Implicit Sharing (1) Improvement (1) JourneyToCTA (1) KPIs (1) Kitchener User Group (1) Large Data Volume (1) LastModifiedDate (1) Metrics (1) Omni-Channel (1) Person Account (1) Photo (1) Platform Developer I (1) Presentation (1) Product Schedule (1) Profile (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Retrieve (1) Role (1) SFDX (1) Salesforce Optimizer (1) Session (1) Sharing (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) Switch (1) SystemModStamp (1) Territory (1) Users (1) Webservice (1) Winter'15 (1) Winter'17 (1) access (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) object (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