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

Kitchener Developer Group Event: Introduction to Lightning Web Component by Mohith Srivastava



Special thanks to our speaker, Mohith Srivastava, for sharing his knowledge on Lightning Web Component. 
Here comes the presentation and recording.

Presentation:

Recording:

Please register to Kitchener, Canada Developer Group for all our future events.
Share:

Notes on passing Salesforce Certified Sharing and Visibility Designer

I have cleared Salesforce Sharing and Visibility Designer certification on Jan 11th, 2019 and it helped me to become Salesforce Application Architect.

Let me quickly share the Exam Outline:
  • Total Number of Questions: 60 multiple-choice/multiple-select questions.
  • Time: 120 minutes
  • Passing Score: 68%
  • Registration Fee: USD 400; Retake Fee: USD 200
  • Prerequisite: None
In this blog post, I will share my notes and experience during the preparation and also during the exam. I hope it will help you in your #JourneyToCTA.

To me questions were very straight forward, but very descriptive, which took a lot of time to go through the entire question. Going through the entire question is very important because one single work can totally change your answer. 

Before I start preparing myself, I have gone through the below blog posts which helped me to create a consolidated list which I am going to share here.
Below are the topics from where I have received questions:

Understanding Profile and Permission Difference

  • Profile is user’s base level permission and all users having the same profile will have the same permission. 
  • Permission Set is assigned to individual users on top of profiles to extend their visibility.
  • You can set Login Ip, Hour, Session Settings, Password policies in Profiles, where these are not possible in permission sets.
  • Profiles are having hidden permission sets.
  • You can set default apps in Profiles, whereas setting default app is not possible in Permission Sets. You can provide app access to both Profiles and Permission Sets.

Difference Between Login Hour and Trusted IP

  • Login IP is set at the profile level. Use case: You want your internal employees will be allowed to login to your org only from corporate network. Anybody trying to login from outside will not be allowed to login.
  • Trusted IP is set at the Network Access / Org level. Anybody trying to login from the defined IP range, will not be asked to verify their identity. Otherwise, they need to verify their identity either through mobile authenticator or through email code.



Usage of System.runAs()

  • It is only applicable in test methods.
  • Since Apex always runs in System mode, user’s sharing settings is not enforced. That is why we need to use System.runAs() to change the user context and then that user’s sharing settings will  be enforced.
  • runAs() method doesn’t enforce user permission or field level permission. It only enforce record sharing.
  • runAs() ignores user licence limits means in test class you can still create users with runAs() even though you don’t have license in your organization.
  • runAs() will allow you to get rid of Mixed DML exception in Test Class.

Sharing Questions:

Sharing for Communities:


Enterprise Territory Management:


Identify Security threats and mitigation approaches:

  • SOQL Injection
  • XSS

Account Team:

  • Account team shares role with Opportunity Team. So removing account team role will eventually remove the role from Opportunity Team as well.
  • Account owner and users above the account owner in the role hierarchy can add, edit, and delete team members.
  • To add account team member, you just need edit access to the account.
  • To edit/delete team members, you have to be -
    • Account owner
    • Above the owner in the role hierarchy
    • Any user who is having full access to the account
    • And administrator
  • Access Levels for Account teams:
    • Only account owners and users above the account owner in the role hierarchy can:
      • Add team members who don’t have even read permission to the account record.
      • Grant team member some access which is higher than account owd. Note - You can only grant greater access, but you will never be able to restrict access.
  • Disabling Account Team:
    • Disabling account team removes the team from all the accounts and also deletes user’s default account team.
  • Removing Account Team Members
    • Removing one user from the account team will not remove the user from opportunity team
    • If a user in your default account team and you remove the user from one account team, then it will impact only that account, not your default account team.
  • Default Account Team
    • This is default account team for each users. User can select their default account team by going to the advanced settings.
    • While defining default account team, you have the option to apply the default account team to all your open accounts.
    • Clicking on “Add Default Team” from the account page layout’s related list will add the default team of the account owner, not the person who is clicking the button. Only Admin and users above the account owner in role hierarchy can add default team in the account.
    • The access level can be set to the same or wider than your owd access.

Other Topics:

  • Encryption in rest and transit
  • Usage of Protected Custom Metadata, Protected Custom Settings, Crypto Class.
  • Apex Managed Sharing and reason to avoid deletion of share record in case of record owner change.
  • How reports, dashboards and folders are shared.
  • List view accessibility.

Recommended Reading:

Share:

Sharing Options and User Licenses in Salesforce Communities

While implementing Salesforce Community, identifying the record access requirements is an important steps which we all should do before procuring user licenses or setting up the communities. The reasons why I am telling this are -
  • Sharing options in Communities depends on the type of Community User License (Customer or Partner)
  • Even with the most open user license (Partner), there are few "gotchas" when it comes to sharing in a Community.
  • You need to adjust internal sharing settings to make sure you are not giving unwanted record access to your community users.

License Types

Salesforce has a great chart here which compares features between Customer and Partner user license. But I prefer the below picture while deciding the license types.
In short, Customer licenses are designed for high-volume applications with any complex sharing requirements. Customer licenses are not having any roles. That is why sharing rules, Apex sharing and manual sharing are not available for Customer licenses.

On the other hand, Partner licenses are having access to more object types. For example, if you want community users should have access to Leads, Opportunities, Campaigns, upload contents then you need Partner license. Partner licenses are having roles so sharing options are available.

In addition to the above two licenses, Salesforce has Customer Plus license which is kind of middle between Customer and Partner license. So if your requirement is that you want your customers to have full access to Accounts, view access to Contents, ability to create Tasks, view access to Reports and Dashboards, and role-based sharing, then you should got for Customer Plus license.
So the difference between Customer Plus license and Partner license is that users with Partner license can access "premium" standard objects Leads, Campaigns, Opportunities.

Sharing Options with Customer License:

We basically have two options here: Sharing Sets and Share Groups. So let's explore both with some use cases so that it will become easier to understand.

Sharing Sets:

Sharing Sets will allow you to grant a external user access to records based on relationship with the user's contact or account (or a contact or account related indirectly to the user through some lookup relationship).
Use Case: Requirement is to share all cases created under the same account to all users in the same community.

Share Groups:

Share Groups allow to share records owned by community users with internal users. Basically you can use Share Groups to share records owned by an External user (with a Customer Community or High-Volume Customer Portal License) with Internal users, partner users, or other High-Volume external users in the same account). 
Use Case: Requirement is to share cases created by external community users with Call Center Reps (Internal users). (Account restriction applies to High-volume external users only).

Important Point to Remember:

  • Sharing Sets:   External User   ->   External User
  • Sharing Group:   External User   ->   Internal User

Sharing Options with Partner License/Customer Community Plus License:

With Partner license, you have five options - Role Hierarchy, Super User Access, Sharing Rules, Manual Sharing, Apex Sharing.

Role Hierarchy:

Each partner account can have 3 roles (Executive, Manager and User). Using record ownership and role hierarchy is the simplest way to share records among Partner users in the same account.
Use Case: Requirement is to allow some partner users to see only those records which they create, whereas for other partner users they should be able to see records created by others below them in role hierarchy.

Super User Access:

Partners with Super User access will be able to see records created by other users in their account at the same level or lower in the role hierarchy, for Cases, Leads, Opportunities and Custom objects only. For Customer Plus users, this can be given through permission sets.

Sharing Rules:

Owner and Criteria based sharing rules can be used to share records within Partner community. You can use Partner Role and public groups in these rules.
Use Case: Requirement is to share all Opportunities related to a particular partner account with all users in the partner account, but don't want to open up the full super user access. Here you can create a criteria-based sharing rule where the AccountId is the partner account and then sharing with partner account executive role and subordinates. 

Manual Sharing:

External users with Customer Community Plus and Partner License can use manual sharing but only on VF Communities. It's in the Salesforce roadmap to add support for lightning communities. Another mechanism for manual sharing is Opportunity team i.e. a reseller shares the opportunity with his SI (co-seller use case).
Use Case: Partners work closely with internal users on few opportunities.

Apex Sharing:

Apex sharing should be used when the sharing requirements are too complex which cannot be implemented with criteria-based sharing rule. Basically this is the last resort you have.

Recommended Reading:

Recent Changes:

Share:

Salesforce Enterprise Territory Management Cheat Sheet

This post is the continuation of my study notes for  Sharing and Visibility Designer Architect Certification. Previous post was regarding Salesforce Sharing and Security Cheat Sheet. Enterprise Territory Management is a very important topic and having a clear understanding will definitely going to help in passing the certification as well as implementing it for your own project.

Important Note:

  • Original Territory Management is only available with Customizable Forecast.
  • Enterprise Territory Management works with Collaborative Forecast. It will not work with Customizable Forecast.

Territory:

Group of Accounts and Sales reps who work for those accounts.

Territory Type:

This is the criteria to group territories. Every territory must have one Territory Type, but it will never appear in the Territory Hierarchy

Territory Type Priority:

Helps you to create priorities for your territory type.

Territory Model:

  • Creates the entire Territory Hierarchy.
  • It allows to create multiple territory hierarchy and test that before activating.
  • Number of territory models depends on the Salesforce edition.

Territory Hierarchy:

  • Shows the model's territory structure.
  • You can run assignment rules at the model level or individual territory levels.
  • Your territory hierarchy in active territory model also determines the forecast hierarchy for territory forecast.

Territory Model State:

  • Three states - Planning, Active or Archive.
  • Only one territory can be in Active state.
  • Multiple territories can be in either Planning or Active state.

User Access for Territory Records:

  • Define Account access in Territory Settings when enabling the Enterprise Territory. You can change it later as well.
  • Account Access is:
    • Users in the territory can view and edit the Accounts in the same territory or
    • Users in the territory can view, edit, transfer and delete the Accounts in the same territory.
  • Contacts, Opportunity and Cases will have the default access defined in Internal Access settings if the access level is either Controller by Parent or Public Read/Write/Transfer.
  • If the Internal Access for Contacts, Opportunities and Cases are configured anything apart from Controller by Parent or Public Read/Write/Transfer, then you can set the access as -
    • View all contacts/cases/opportunities associated with Accounts in the same Territory irrespective of who owns the contact/case/opportunity.
    • View and Edit all contacts/cases/opportunities associated with Accounts in the same Territory irrespective of who owns the contact/case/opportunity.
  • This settings can be changed when creating Territories. You can change it to make it more restrictive (Territory Settings : View and Edit, whereas Territory Hierarchy Settings: View, Edit, Transfer and Delete) as well.
  • Territories access level is inherited by the parent territories above it in the territory hierarchy. Example: India (View and Edit) is the parent of Kolkata (View). Users assigned to India territory will have View access to Accounts assigned in Kolkata territory.

Assigning Territories to Accounts:

  • "Manage Territories" permission is required to assign accounts to territories.
  • Either manually assign accounts or write assignment rules.
  • Assignment rules can be inherited to child territories by selecting the option while creating the assignment rule. If selected, the criteria from the parent territories is not required to be mentioned in the child territories assignment rules.
  • Accounts can be associated with multiple territories.
  • Manually added Accounts will remain in the Territories until and unless it is removed manually.

Assigning Territories to Users:

  • When users moved to a new Territory. they have the option to take their existing Accounts and Opportunities with them,

Assigning a Territory to an Opportunity:

  • From the opportunity detail page, select the territory.
  • You will only get those territories where -
    • Both the opportunity owner and opportunity's account owner are present,
    • you have administrative access and also associated with opportunity's account.
    • you have administrative access that are above the opportunity's account in the territory hierarchy.

Filter based Opportunity Territory assignment:

Assigning Territory Roles to Territory Users:

  • You can define custom roles under User Territory Assignment -> Role in Territory.

Optimize Performance:

  • Always select inherited rules to child territories which will prevent rule engine to evaluate more territories and thus improving performance.
  • Always start with the lowest level of territory hierarchy and then move upwards. With this approach, it will not recalculate Account, Contact, Opportunity, Case access for the same territories.
  • Always define criteria on Numeric fields, rather than String field while creating assignment rules.
  • Keep the assignment rule restrictive by avoiding lots of OR condition.
  • More than 10,000 records associated with single territory will always create performance issues.
  • For best performance, single user should not be liked with more than 3 territories.
  • If needed more users (more than 1,500 users) in a single territory, better to use user-to-territory assignment through API.
  • You should not run assignment rule for each Account update. You can eliminate that by not selecting the option evaluate this account against territory rules on save. The reason is even though you are editing single account, but the assignment rule will run for all the accounts, which can cause performance issues.

Difference between Role Hierarchy and Territory Hierarchy:

  • Role Hierarchy is perfect for managing organization structure where one person reports to only one person.
  • Territory Hierarchy is perfect for managing matrix reporting structure where one person reports to multiple person.

When to use what? Role Hierarchy or Territory Hierarchy:

  • You should use Role hierarchy to use implement your organization hierarchy, reporting rollups, approvals.
  • Then use Territory hierarchy to extend access to records based on user's territory assignment.

Forecast Manager:

  • To see the rolled-up forecast, assign Forecast manager to parent territory.
  • Forecast manager can view and adjust forecasts.
  • Without Forecast manager,  users can view and adjust only their own forecasts, but can't adjust other's forecast.
Please let me know if you think I should add something here in the comment section.
Share:

Salesforce Sharing and Security Cheat Sheet


"Sharing is Caring", right?? That's the attitude I like most about Salesforce Ohana. As I am preparing myself for Sharing and Visibility Designer Architect certification, I thought of sharing some of my study notes regarding Salesforce Sharing and Security.

Security is the main pillar of Salesforce eco system and it is complex. It will give you fine-grained control over data access. So it requires a very good understanding of the concepts to implement in correctly.

I will suggest everyone to go through these below articles to understand it clearly.
I am not going to write everything what is written in these documents, rather I would like to provide a concise, sharp cheat sheet which you can refer anytime. So let's start -

Sharing Metadata Objects/Records:

  • For standard object -> "Object[Share]"
  • For custom object -> "Object__[Share]"
  • Contains three types of sharing -> managed sharing, User managed sharing and Apex managed sharing
  • Fields present in the share object - access level, record ID, user or group ID
  • Share records are not created for OWDs, role hierarchies, or the "View All"/"Modify All"/"View All Data"/"Modify All Data" permissions.
  • If the owner of the record changes, sharing record with reason "Manual" will also be deleted.

Implicit Sharing:

  • This is applicable only for Accounts, Contacts, Cases and Opportunities.
  • Access to parent record - If you have access to one of the child record, you will have Read Only  access to the parent record.
  • Access to child record - If you have access to parent record, you will have access to all child records(Contacts, Cases and Opportunities). 

Organization Wide Defaults (OWD):

  • Grant access using hierarchies is enabled by default for standard objects (You cannot disable the same). For custom objects, you can enable/disable this property.
  • Can't be changed for contacts if person accounts are enabled.

Master Detail:

  • Access is controlled by parent record.
  • Child record will not have any share record of their own.
  • It is not possible to write sharing rule for child object.
  • Only parents in the M:D relationship will have the owner.
  • If the detail object is having more than one master record, then first M:D created will become the primary relationship.

Lookup:

  • Child object can have their own sharing access level and ownership.

Manual Sharing:

  • Removed when owner changes.
  • Removed when OWD becomes at least as permissive as share.
  • Private contacts (without Accounts) cannot be manually shared.

Apex Managed Sharing:

  • Using Apex code to share the record.
  • Requires "Modify All" permission.

Ownership-based Sharing Rules:

  • When you want to share records owned by user, group, queue or role with another user, group, queue or role (including portal users with role).

Criteria-based Sharing Rules:

  • When you want to share records based on values of a specific field or fields with another user, group, queue or role (including portal users with role).

Manual Sharing Rules:

  • When the record owner or someone with "Modify All" permission wants to share individual record with another user, group, queue or role (including portal users with role).

Share Group:

  • You want to share records owned by HVP users with internal users, groups or roles (includes portals users with roles)

Sharing Sets:

  • You want to share records with HVP users. Records should fulfill the below criteria:
    • Object's OWD is different than Public Read/Write.
    • Object is available for Customer Portal.
    • Custom object is having a lookup field to account or contact.

Portal - High Volume Portals (Service Cloud Portals):

  • Include High Volume Customer Portal and Authenticated Website profiles. 
  • They have no roles and can’t participate in “regular” sharing rules.
  • You can share their data with internal users through Share Groups.
  • You can share object records where the object is a child record of the HVP user’s contact or account. This is done with Sharing Sets.
  • They can also access records that are:
    • Available for portals
    • Public R/W OWD or
    • Private OWD and They own the record.
  • They can access a record if they have access to that record’s parent and the OWD is set to “Controlled by parent”.
  • Cases cannot be transferred from non-HVP to HVP users

Large Data Volumes:

  • Defer sharing settings (enabled by logging a case) and group calculation on large data loads and modifications.
If there is anything you think I should put in this list, please mention the same in comment. I will be more than happy to put the same here.

I hope this cheat sheet will give you a very good summary of Salesforce Sharing.


Share:

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) Certification (7) Trigger (7) test class (7) unit testing (7) Advanced Admin (6) Sharing and Visibility (6) design pattern (6) developer (6) report (6) salesforce release (6) security (6) trailhead (6) Advanced Apex (5) 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) 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) Asynchronous callout (2) 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) PD II (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 Apex (1) Aura Framework (1) Batch (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) Future (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) Partner (1) Person Account (1) Photo (1) Pipeline (1) Platform Developer I (1) Platform Developer II (1) Presentation (1) Product Schedule (1) Profile (1) Promise (1) Prototype (1) Public Site (1) Query Plan (1) Queueable (1) QuickReference (1) Reports (1) Retrieve (1) Role Hierarchy (1) SFDX (1) Salesforce Optimizer (1) Schedule (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)

Total Subscribers

Total Pageviews