Here we’re discussing 2 approaches if you’re looking for answer to how you can use dynamic hide/show in LWC without template if:true approach

Toggle Class (Simple Approach)

Toggle (classList Approach)

Source https://salesforce.stackexchange.com/questions/260614/lwc-how-to-toggle-css-class-on-button-click

But using lightning:input or lightning-input, we’re not allowed to add HTML tags under LABEL attribute.

So here are the work-arounds for AURA and LWC,

AURA

Component:

<aura:attribute name="chkTerms" type="Boolean"/>
<div>
    <input type="checkbox" id="terms" name="terms" value="{!v.chkTerms}" onchange="{!c.termsChanged}" ></input>
    <label for="terms"> Yes, by creating an account I agree to the <a href="#">Terms and Service.</a></label>
</div>

JS

termsChanged : function(cmp, event, helper){
    cmp.set("v.chkTerms", document.getElementById("terms").checked );
    //console.log(event.getSource().get("v.checked"));
    // the above didn't work except for `ui:input` or `lightning:input`
    console.log(cmp.get("v.chkTerms") ); 
}

LWC

HTML

<div class="slds-p-around_medium lgc-bg">
    <input type="checkbox" id="terms" name="authorize" onchange={handleCheckBoxChange} required="required"></input>
    <label for="terms" style="display: inline;" class="slds-form-element__label"> Yes, by creating an account I agree to the <a href="#">Terms and Service.</label>
</div>

JS

handleCheckBoxChange(event){        
    console.log('Authorized::'+event.target.checked);
    // Your Logic
}

Source
https://salesforce.stackexchange.com/questions/213749/lightninginput-checkbox-label-with-url

Mansoor Ahmed showed us some top free apps from app exchange for our daily use.

Sandhya Bajaj helped us get started with Salesforce flows

Presentations : Flows : https://docs.google.com/presentation/d/1RP-P8-fhRry0GAZeLuNkin3mC1rPcOwp1YX1_r7TJP8/edit?usp=sharing

Basically it is saying that you cannot declare a list of type sObject and then try to use the upsert command against that list. That limitation can make coding generic routines difficult which do not know the specific object type up front. For example, I might be building a table driven integration layer where the user will determine, by updating a custom field or custom setting, what the name of the destination custom object will be. With this approach I will need to use the generic sObject data type, but that will stop me from using the upsert database command.

Bummer! What to do?

Here is a link that describes this problem very clearly and jangiz at the bottom describes the correct work-around approach.

Here is some code to implement that work-around that jangiz described:

Wow, what a bunch of work when I really just wanted to write…
upsert sObjList myExternalIDField

But as long as there is a manageable work-around I can at least move forward!

Good luck with your Apex today!

Source : https://www.sundoginteractive.com/blog/generic-sobjects-salesforce

Modes

The component accepts a mode value that determines the user interaction allowed for the form. The value for mode can be one of the following:

• edit – Creates an editable form to add a record or update an existing one. When updating an existing record, specify the recordId. Edit mode is the default, and as such, can be omitted.
• view – Creates a form to display a record that the user can also edit. The record fields each have an edit button.
• readonly – Creates a form to display a record without enabling edits. The form doesn’t display any buttons.

For all modes, the component expects the fields attribute, the layout-type attribute, or both. Use the fields attribute to specify a comma-separated list of record fields to load into the form. The fields load in the order you list them. Use the layout-type attribute to specify a Full or Compact layout. All fields that have been assigned to the layout are loaded into the form. This is the same behavior as the Lightning Data Service’s force:recordData object. Layouts are typically created or modified by administrators. Loading record data using layout-type allows the form to adapt to those layout definitions. If you provide the fields attribute and the layout-type attribute, the fields specified in the fields attribute are loaded before the layout fields.

This component takes care of field-level security and sharing for you, so users see only the data that they have access to.

Creating a Record

Use mode="edit" and pass in the object API name for the record to be created. Do not specify a recordId. Specify the fields using the fields attribute, or layout-type="Full" attribute to load all the fields defined on the full layout.The compact layout cannot be used for creating records. If you specify layout-type="Compact", the full layout is shown. If you specify the fields attribute, be sure to include any fields that are designated as required for the object’s records. Because no recordId is passed, edit mode loads the form with input fields that aren’t populated with field data. The form displays Submit and Cancel buttons.This example creates an editable two-column form with the full layout and additional fields. The form is used for creating records in an Account object. The onsubmit attribute specifies an action to override the handler for the submit.

Create a Lightning web component using the below SFDX command

sfdx force:lightning:component:create --type lwc --componentname recordform --outputdir force-app\main\default\lwc

Use the below recordform.html code

<template>    
<lightning-record-form object-api-name="Account" layout-type="Compact" columns="2" mode="edit"     onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form></template>

Use the below recordform.js code

import {LightningElement,api} from 'lwc'; 
export default class Recordform extends LightningElement {     
  handleSubmit(event) {        
   console.log(event.detail)    
  }    
  handleSuccess(event) {        
   console.log('Record iD' + event.detail.id);     
  }
}

Use the below recordform.js-meta.xml code

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="helloWorld">    <apiVersion>45.0</apiVersion>    
<isExposed>true</isExposed>    
<targets>        
  <target>lightning__RecordPage</target>    
</targets>
</LightningComponentBundle>

Push the changes and add this component to the record page layout. you can able to see the complete record create a form

Now let’s see how to use create a record with specific fields. Now update the recordform.html code as shown below

<template>    
<lightning-record-form object-api-name={accountObject}  fields={myFields} mode="edit" onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form>
</template>

Use the below recordform.js code which will be passed to the record form.

import {LightningElement,api} from 'lwc';
import ACCOUNT_OBJECT from '@salesforce/schema/Account';
import NAME_FIELD from '@salesforce/schema/Account.Name';
import WEBSITE_FIELD from '@salesforce/schema/Account.Website';

export default class Recordform extends LightningElement {      
 accountObject = ACCOUNT_OBJECT;     
 myFields = [NAME_FIELD, WEBSITE_FIELD];         
 handleSubmit(event) {        
  console.log(event.detail);    
 }    
 handleSuccess(event) {        
  console.log('Record iD' + event.detail.id);     
 }
}

Push the changes and you can able to see the create form with two fields as shown below.

Editing a Record

If you do not specify the mode attribute, its default value is edit. To edit a record, pass the ID of the record and the corresponding object API name to be edited. Specify the fields using the fields attribute, or layout-type attribute to load all the fields defined on the Full or Compact layout. When record-id is passed, edit mode loads the form with input fields displaying the specified record’s field values. The form also displays Submit and Cancel buttons. This example creates an editable two-column form with a compact layout and additional fields. The form is used for editing records in an Account object. The onsubmit attribute specifies an action to override the handler for the submit. Update the recordform.html code as shown below.

<template>    
<lightning-record-form record-id={recordId} object-api-name="Account" layout-type="Full" columns="2" mode="edit" onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form>
</template>

update the recordform.js code as shown below.

import {LightningElement, api} from 'lwc'; 
export default class Recordform extends LightningElement {    
 @api recordId;    
 handleSubmit(event) {      
  console.log(event.detail);  
 }    
 handleSuccess(event) {       
  console.log('Record iD' + event.detail.id);    
 }
}

Use mode="view" and pass the ID of the record and the corresponding object API name to be displayed. Specify the fields using the fields attribute, or layout-type attribute to display all the fields defined on the Full or Compact layout.

the following code shows the how to edit the specific fields instead of layouts.update the recordform.html code as below.

<template>    
<lightning-record-form object-api-name={accountObject} record-id={recordId}  fields={myFields} mode="edit"        
onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form></template>

update the recordform.js code as shown below.

import {    LightningElement,    api} from 'lwc';
import ACCOUNT_OBJECT from '@salesforce/schema/Account';
import NAME_FIELD from '@salesforce/schema/Account.Name';
import WEBSITE_FIELD from '@salesforce/schema/Account.Website';

export default class Recordform extends LightningElement {     
@api recordId ;      
accountObject = ACCOUNT_OBJECT;     
myFields = [NAME_FIELD, WEBSITE_FIELD];  
       
handleSubmit(event) {       
 console.log(event.detail);   
}    
handleSuccess(event) {       
 console.log('Record iD' + event.detail.id);    
 }
}

Now you can able to see the changes as shown below with the specified fields.

Viewing a Record Read-Only

The simplest way to display a record is to use the lightning-record-form. You can display a record in two modes.viewLoads the form using output fields with inline editing enabled. Editable fields have edit icons. If a user clicks an edit icon, all fields in the form become editable, and the form displays Submit and Cancel buttons.read-onlyRead-only mode loads the form with output fields only. The form doesn’t include edit icons, Submit and Cancel buttons.

This code displays an account record in view mode using the compact layout, which includes fewer fields than the full layout.

Use mode="readonly" and pass the ID of the record and the corresponding object API name to be displayed. Specify the fields using the fields attribute, or layout-type attribute to display all the fields defined on the Full or Compact layout. The read-only mode loads the form with output fields only, and without Submit or Cancel buttons.The following code specifis how to use the read-only mode. Use the below recordform.html code.

<template>    
<lightning-record-form record-id={recordId} object-api-name="Account"     
layout-type="Full" columns="2" mode="readonly"         
onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form>
</template>

You can able to see the record with read-only data .

Let’s update the code with view mode as shown below. view Loads the form using output fields with inline editing enabled. Editable fields have edit icons. If a user clicks an edit icon, all fields in the form become editable, and the form displays Submit and Cancel buttons.

Update the code as shown below and you can able to see the edit icon

<template>    
<lightning-record-form record-id={recordId} object-api-name="Account" layout-type="Full"     columns="2" mode="View" onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form></template>

Using Record types

If your org uses record types, picklist fields display values according to your record types. You must provide a record type ID using the record-type-id attribute if you have multiple record types on an object and you don’t have a default record type. Otherwise, the default record type ID is used. Display a record create a form based on a record type by providing the record-type-id attribute. This example shows a form that you can place on an account record page. The form displays fields, which include a picklist with values based on the given record type Id.

<lightning-record-form object-api-name={objectApiName} record-type-id={recordTypeId}                 fields={fields}></lightning-record-form>

Error Message

To enable automatic error handling, include the component lightning-messages.To customize the behavior of your form when it loads or when data is submitted, use the onload and onsubmit attributes to specify event handlers. Errors are automatically handled. To customize the behavior of the form when it encounters an error on submission or when data is submitted successfully, use the onerror and onsuccess attributes to specify event handlers

<template>            
<lightning-messages></lightning-messages>     
<lightning-record-form record-id={recordId} object-api-name="Account" layout-type="Full"     columns="2" mode="View" onsuccess={handleSuccess} onsubmit={handleSubmit}>    
</lightning-record-form></template>

Source : https://rajvakati.com/2019/02/16/lightning-record-form/

Import Syntax 

You can able use default export syntax to import an Apex method via the @salesforce/apex scoped module into JavaScript controller class. The Syntax looks like below.Default

import apexMethod from '@salesforce/apex/Namespace.Classname.apexMethod';

apexMethod—The imported symbol that identifies the Apex method.
Namespace—The namespace of the Salesforce organization. Specify a namespace unless the organization uses the default namespace (c), in which case don’t specify it.
Classname—The name of the Apex class.

Create Apex Class 

In this example, we will be getting account data and show it into the UI. Create an apex class using SFDX create apex class command.Default

sfdx force:apex:class:create -n GetAccountData -d force-app/main/default/apex

Here is the apex class. To expose an Apex method to a Lightning web component, the method must be static and either global or public. Annotate the method with @AuraEnabledDefault

public with sharing class GetAccountData {
   @AuraEnabled(cacheable=true)
    public static List<Account> getAccountList() {
        return [SELECT Id, Name,Type,Rating,Phone FROM Account];
    }
}

Now you can able to call the apex class in  Lightning web component using these different ways.

• Wire a property
• Wire a function
• Call a method imperatively

Wire an Apex Method to a Property

If an Apex method is annotated with @AuraEnabled(Cacheable=true), you can invoke it from a component via the wire service. You can @wire a property or a function. Here is the syntaxDefault

import apexMethod from '@salesforce/apex/Namespace.Classname.apexMethod';
@wire(apexMethod, { apexMethodParams })
propertyOrFunction;

Create a Lightning web component using below SFDX commandsDefault

sfdx force:lightning:component:create --type lwc -n LWCWireEx -d force-app/main/default/lwc

Here is the LWCWireEx.html markup for the lightning web components.Default

<template>
    <lightning-card title="Apex Class Example" icon-name="custom:custom63">
            <div class="slds-m-around_medium">
                <template if:true={accounts.data}>
                    <template for:each={accounts.data} for:item="acc">
                        <p key={acc.Id}>{acc.Name}</p>
                    </template>
                </template>
                
            </div>
        </lightning-card>
</template>

Here is the LWCWireEx.js classDefault

import { LightningElement, wire } from 'lwc';
import getAccountList from '@salesforce/apex/GetAccountData.getAccountList';

export default class LWCWireEx extends LightningElement {
    @wire(getAccountList) accounts;
}

Here is the LWCWireEx.js-meta.xml markup.Default

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>45.0</apiVersion>
    <isExposed>false</isExposed>
    <targets>
        <target>lightning__RecordPage</target>
       </targets>
</LightningComponentBundle>

Push the changes to scratch org and add the lightning web component to the record page. You can able to see the result like below.

Wire an Apex Method to a Function

Now let’s look at how to wire an apex method to function.we will be updating the same code here to operate the apex method as function.

Update the LWCWireEx.js class as shown belowDefault

import { LightningElement, wire,track } from 'lwc';
import getAccountList from '@salesforce/apex/GetAccountData.getAccountList';

export default class LWCWireEx extends LightningElement {
    @track accounts;
    @track error;
    @wire(getAccountList)
    wiredAccounts({ error, data }) {
        if (data) {
            this.accounts = data;
        } else if (error) {
            console.log(error);
            this.error = error;
        }
    }
}

update the LWCWireEx.html markup as shown belowDefault

<template>

    <lightning-card title="Apex Wire To Function Example" icon-name="custom:custom63">

        <div class="slds-m-around_medium">
            <template if:true={accounts}>
                 <ul>
                <template for:each={accounts} for:item="account">
                    <li key={account.Id}> {account.Name} </li>
                </template>
             </ul>
            </template>
            <template if:true={error}>
                {error}
            </template>                
        </div>
    </lightning-card>
</template>

Push the changes to scratch org and add the lightning web component to the record page. You can able to see the result like below.

Call an Apex Method Imperatively

Now let’s see here how to call apex method imperatively. Create a new Lightning web component using the below SFDX commandDefault

sfdx force:lightning:component:create --type lwc -n ImperativEx -d force-app/main/default/lwc

Use the below ImperativEx.html codeDefault

<template>
        <lightning-card title="Apex Imperative Method Example">
            <div class="slds-m-around_medium">
                <p class="slds-m-bottom_small">
                    <lightning-button label="Load Accounts" onclick={handleLoad}></lightning-button>
                </p>
                <template if:true={accounts}>
                    <template for:each={accounts} for:item="account">
                        <p key={account.Id}>{account.Name}</p>
                    </template>
                </template>
                <template if:true={error}>
                   {error}
                </template>
            </div>
        </lightning-card>
    </template>

Use the below ImperativEx.js class codeDefault

import { LightningElement, wire,track } from 'lwc';
import getAccountList from '@salesforce/apex/GetAccountData.getAccountList';


export default class ImperativEx extends LightningElement {
    @track accounts;
    @track error;
    handleLoad() {
        getAccountList()
            .then(result => {
                this.accounts = result;
            })
            .catch(error => {
                this.error = error;
            });
    }
}

Use the below ImperativEx.js-meta.xml class codeDefault

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="hello">
    <apiVersion>45.0</apiVersion>
    <isExposed>false</isExposed>
     <targets>
        <target>lightning__RecordPage</target>
    </targets>
</LightningComponentBundle>

push the changes to scratch org and add the lightning web component to the record page and you can able to see the below result when you click on the button .

Call an Apex Method with Parameters

Pass parameters values to an Apex method in an object whose properties match the parameters of the Apex method. For example, if the Apex method takes a string parameter, don’t pass a string directly. Instead, pass an object that contains a property whose value is a string.

// apexImperativeMethodWithParams.js

import { LightningElement } from 'lwc';
import findContacts from '@salesforce/apex/ContactController.findContacts';

export default class ApexImperativeMethodWithParams extends LightningElement {
    searchKey = '';
    contacts;
    error;

    handleKeyChange(event) {
        this.searchKey = event.target.value;
    }

    handleSearch() {
        findContacts({ searchKey: this.searchKey })
            .then((result) => {
                this.contacts = result;
                this.error = undefined;
            })
            .catch((error) => {
                this.error = error;
                this.contacts = undefined;
            });
    }
}

public with sharing class ContactController {
    @AuraEnabled(cacheable=true)
    public static List<Contact> findContacts(String searchKey) {
        String key = '%' + searchKey + '%';
        return [
            SELECT Id, Name, Title, Phone, Email, Picture__c
            FROM Contact
            WHERE Name LIKE :key AND Picture__c != NULL
            WITH SECURITY_ENFORCED
            LIMIT 10
        ];
    }
}

The exam really tested me on sharing, role hierarchy, territory management and apex sharing. Just one more exam to get my Application Architect.

Update

A lot of people asked for tips for this exam and rather than reply to everyone, I just posted here.

67% of the exam is on declarative sharing. So if you nail this section you have a good chance of passing.

• Make sure you understand what Run as does in testing, as I had two questions on it.
• Make sure you understand difference between territory management 1.0 and territory management 2.0
• Do the security trailhead and remember that escape=false is a cross script issue and not using bind variables in SOQL is a SOQL injection issue. I had two questions on the topic.
• Lots of questions on what happens to a manual share, if the record owner changes.
• Lots of questions on why you should use a custom share reason for apex sharing.
• Lots of question on data skew
• Lot of questions on granular locking and deferred sharing calculation.

Salesforce Certified Sharing and Visibility Designer Exam Tips

4th February 2018GemmaArchitecture Certifications, Salesforce

If you’ve ever been a Salesforce #AwesomeAdmin, you’ll find the Sharing and Visibility Designer exam to be one of the simpler ones. I’ve heard from a few developers lately that they, on the other hand, have found this to be one of the hardest in the architect pyramid. Well, with this blog post, I aim to take away some of the difficulty for you.

What Sharing and Visibility Means

The concept of Sharing and Visibility doesn’t just refer to permissions; in fact, there are a number of different features in Salesforce that contribute to data security. The architect certification aims to test your knowledge at a holistic level: given any scenario that they can throw at you, how would you achieve what the client wants?

As always, your best friend for this exam is the Resource Guide. Here is a breakdown of things you need to know to pass.

Sharing Architecture

Org-Wide Defaults (OWD)

These are applied per object (note that objects related via master-detail relationship will inherit the OWD from their parent). There are 3 types:

• Public Read Write: A free-for-all; everyone can see and change any record
• Public Read Only: Everyone can see and search for the record, but only the owner and those who are positioned above the owner in the role hierarchy can change it
• Private: Only the owner and those above them in the role hierarchy can find or change the record

The moment you have a requirement from somebody to keep a piece of data hidden away or uneditable for certain people, your OWDs need to be changed.

Role Hierarchy

• Typical clients will try to set this up using their organisational structure – and that’s fine as long as that structure also reflects how data should be shared. Obviously, if everything is Read/Write, that matters a lot less.
• Users are assigned a role when they’re first set up.
• Note that if you have any users who will own millions of records, it’s best practice to make sure that user has no role, to optimise performance.
• A typical role hierarchy could be:
  • CEO (Cheryl)
    • COO (Colin)
      • VP of Sales (Sarah)
        • Field Sales Manager
          • Field Sales Team Lead
            • Field Sales Rep
        • Inside Sales Manager (Simon)
          • Inside Sales Team Lead (Denise)
            • Inside Sales Rep (Martin)
        • Strategic Accounts Manager (David)
          • Strategic Accounts Team Lead
            • Strategic Accounts Rep
      • VP of Customer Service
        • Customer Service Manager
          • Customer Service Team Lead
            • Customer Service Agent

You get the picture. So if your OWD for Opportunities is Private, and the owner is Martin:

• Martin can see and edit his own opportunities
• Denise can see and edit her own opportunities, as well as Martin’s and any other Inside Sales Reps’ Opportunities
• Simon can see and edit his own opportunities, as well as Martin’s, Denise’s and any other Inside Sales Reps’ Opportunities
• Sarah can see and edit her own opportunities, as well as any Opportunity owned by any users beneath her – across field sales, inside sales and strategic accounts.
• Colin can see exactly the same as Sarah. He wouldn’t usually own any opportunities of his own.
• Cheryl has visibility across the entire organisation – as well as her own opportunities. Should Cheryl need to set up any opportunities of her own, they would only be visible and editable to her under this sharing model.

Check out my Ladies Be Architects study group and quiz on sharing architecture:

Sharing Grants

Let’s say that for this example, our CEO Cheryl’s opportunities need to be shared with the Strategic Accounts Manager, David, as well as the VP of Sales, Sarah.

There are a few ways you could share Cheryl’s opportunities with these individuals:

• Sharing rules:
  • Cheryl could have a blanket rule that says any opportunities she owns should automatically be shared with David and Sarah’s roles on a Read/Write basis.
  • Cheryl could also have a blanket rule that says any opportunities she manages with a Type of “Strategic” should automatically be shared with David and Sarah’s roles on a Read/Write basis
• Manual sharing:
  • Cheryl could just click “Sharing” and give Read/Write permission to David and Sarah. That’s useful on a case-by-case basis.
• Team sharing:
  • Adding David and Sarah to Cheryl’s default Account team would grant Read/Write access to Accounts owned by Cheryl, and their related opportunities (if that’s what’s needed)
  • Cheryl could also add David and Sarah to the Account team of any individual Accounts that she owns, thus granting access to the Account and related opportunities
  • Adding David and Sarah to the Sales Team of her opportunities on a case-by-case basis would grant Read/Write access
  • Note: the same can apply to Cases via Case Teams.
• Apex sharing:
  • This is the sort of thing you’d want to do when you’ve exhausted all other options and the use case just doesn’t fit the above. Get a developer to write some fancy Apex.
  • Each object in the database also has a “share” table. Using Apex, a developer can add entries to a Share table and thus grant access.
    • Example: a Project record with numerous objects related to it via Lookup. You want to share all related records with the owner – use an Apex sharing rule.

Account Territories

Territory hierarchies are ways you can allocate an account to multiple territories, based on the structure of your sales strategy. Learn more about this in the Ladies Be Architects study group slides. You will need to

• Understand what the right use cases are for Territory Management
• Understand the trade-offs if you choose to implement it
• Have some practical experience of setting it up (even if you just mock it up in a trailhead playground, it helps)

Ladies Be Architects’ first study group session took a look at Enterprise Territory Management in detail:

Sharing architecture is easily referred to in this handy pyramid that Salesforce provides in its Guide to Sharing Architecture:

Security

Controlling access to Files

Become familiar with the following concepts:

• the File Owner
• a File Collaborator
• File Viewer

…and the ways you can share files with these individuals.

Why Salesforce has record owners

There is a great article in the Resource Guide that will help you understand how and why Salesforce went against tradition and opted for an ownership model when it developed its platform. It also goes into great detail about how this works under the bonnet – I’d highly recommend studying this.

Custom Permissions

Custom permissions are pretty cool ways to restrict user permissions within a set use case. For example, according to the help guide, “…you can define access checks in Apex that make a button on a Visualforce page available only if a user has the appropriate custom permission.”. Just another handy tool when you’re designing applications.

Controlling Access to Reports and Dashboards

Know your folder access levels. For a bonus, understand that you can protect these further using two-factor authentication. Did you know you can force people to enter an authorisation code to view reports? Neither did I. It tends to come up in the Identity and Access Management exam, but is additionally useful for this one too.

External Objects

If you’re not familiar with Salesforce Connect, it’s time to get familiar. Study the guide, but remember these principles:

• External objects are treated like custom objects in the API
• External objects are a way to expose tables from an external database within Salesforce.
  • You can add your own fields, but these fields are only populated inside Salesforce.
  • You can’t send this extra data back to its source; you’ll need to integrate via the API to do that.
  • They’re clever enough to link via an external ID.
    • For example, if you’re exposing Orders from SAP in an external object and the order has a customer ID number you already keep in Salesforce, you can create an indirect lookup to link that Order record to an Account in Salesforce. Fancy!

Implicit Sharing

Know what gets shared automatically and how. Difficult and lengthy to explain here, but this article will explain the types of implicit sharing listed here:

• Parent
• Child
• Boss
• Portal
• Community
• Community Parent

Sharing Between Internal and External Users

• Sharing records
  • Owned by high-volume community users (who don’t have roles) to internal and external users – share groups are your friends!
  • To high-volume community users (who don’t have roles) – sharing sets for the win! (“A sharing set grants high-volume users access to any record associated with an account or contact that matches the user’s account or contact.”)

Encryption

I’d highly recommend studying

• best practices encrypting custom fields
• the differences between platform encryption and classic encrypted fields
• the Apex Crypto class

Handling Large Data Volumes

If you’ve already passed the Data Architecture and Management certification exam, this should be easier than you’d expect. Here’s where the crossovers are:

• Reducing the risk of lock contention
• The impact of ownership skew and how it can be avoided
• Group membership sharing
  • setting up sensible public groups to optimise performance
  • avoiding too many records in the object’s share table by adding people to groups and sharing with the group
    • As a rule, I tend to go
      • Person —> belongs to a Role
      • Role or Role and Subordinates —> belongs to a public group
      • Territory —> belongs to a public group
      • Group —> belongs to a queue…..

but you can use other groups and individual users too. The principle is to try to share with the topmost level in your group architecture, but the article provided by Salesforce explains it much better than I can.

Overall, I found this to be an enjoyable exam which I look forward to studying again when I take my CTA certification!

References :

https://www.reddit.com/r/salesforce/comments/7x7zjb/i_passed_the_sharing_and_visibility_designer_exam/

http://www.alwaysablezard.com/salesforce/salesforce-certified-sharing-visibility-designer/