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

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:

Happy New Year and Keep Learning


Once again, the start of a brand new year has come upon us. As we enter into new possibilities, may we all be reminded that we have the ability to be, do, and have anything that we want; that there are no mistakes, only lessons; and that the love and happiness we seek is already within our grasp.  It’s easy to make resolutions and renew our commitments.

As we begin 2019, my prayer is that we continue to grow and find the space within ourselves to know, beyond all doubt, that there is nothing more that we need to do in order to be complete. We don’t need a new exercise plan, more money, a better job, a new car or a bigger house. All we need is a willingness to allow ourselves to feel good and to be at peace in the present moment. All we need is gratitude for all that we have, and all that we have had the pleasure to be and to experience. That is the starting point from which all other things will flow into our existence.
Thank you for the wonderful support that you have given me through the past year! Wishing you a wonderful new year!
2018 was great journey for me both professionally and personally. I would like to share some really important moments -
  • I left Cognizant and joined Appirio Inc., a Wipro company. Leaving Cognizant was really difficult for me, because Cognizant gave me all kind of supports during my Salesforce journey. So Cognizant will always remain special. But Appirio is a company I was always dreaming to be part of. Journey with Appirio is awesome. I met so many great colleagues who are not only great in Salesforce, but more that that, they are great human being. I am enjoying every bit of my Appirio journey.
  • I was feeling so bad leaving my Manulife team and I am still missing the team. I met the greatest team ever in Manulife. 
  • I went to Dreamforce'18. It was HUGEEEEEEE... Again thank you Appirio for giving me the opportunity to be part of Dreamforce.
  • I became leader of Kitchener, CA Developer Group and thank you to Salesforce for giving me the option to contribute to our Salesforce Ohana.
Events from Kitchener, CA Developer Group:
Share:

SalesforceDX : Explaining Scratch Org Definition File


Scratch Org definition file is getting used to create the shape of your scratch org. I would say it is the blueprint of your scratch org. You can use this definition file to create multiple scratch org from your repository.


Scratch org definitions come from JSON text files that are stored in your project's repository and directory structure. When an SFDX project is first created, it comes with a config/project-scratch-def.json file that defines an extremely basic org "shape" for an empty scratch org.
That default scratch org likely looks nothing like your production org. You can use it for developing functionality that isn't dependent on your org's settings, or you can customize it using the settings that are available as part of the configuration file, or you can script your process to perform Metadata API deploys or other API actions to control settings that DX does not support yet.
Ideally, the combination of your DX source code (including all your programmatic and declarative customization) with your scratch org definition gets you close enough to Prod instance.

This definition file contains three main important information about your scratch org.
  • Which Edition? As of Winter'19, it supports Developer, Enterprise, Group or Professional
  • Add-on features: Functionalities you want to include while creating the scratch org like communities, StateAndCountryPicklist, LiveAgent etc.
  • Settings: Org and Feature settings used to configure Salesforce products, such as nameSettings, ideaSettings, caseSettings, omniChannelSettings.
Let's dig into a Scratch Org definition file now -

{
    "orgName": "Sudipta Deb Company",
    "username": "[email protected]",
    "adminEmail": "[email protected]",
    "description": "This is the scratch org created by Sudipta Deb",
    "edition": "Enterprise",
    "features": ["Communities", "StateAndCountryPicklist", "LiveAgent"],
    "settings": {
        "orgPreferenceSettings": {
            "s1DesktopEnabled": true,
            "networksEnabled": true,
            "chatterEnabled": true
        },
        "nameSettings": {
            "enableMiddleName": true,
            "enableNameSuffix": true
        },
        "quoteSettings": {
            "enableQuote": true
        },
        "liveAgentSettings": {
            "enableLiveAgent": true
        },
        "omniChannelSettings": {
            "enableOmniChannel": true
        },
        "ideasSettings": {
            "enableIdeas": true
        },
        "caseSettings": {
            "emailToCase": true
        }
    }
}

Now let me explain different parts of this definition file -
  • orgName:  It is just giving a name of your organization in the scratch org. 
  • username: username of the scratch org user
  • adminEmail: Email address of the Dev Hub user making the scratch org creation request.
  • edition: provides the Salesforce edition of the scratch org.
  • description: Giving description of the scratch org. It's a good practice to provide description.
  • features: In my example, I am enabling communities, StateAndCountryPicklist, LiveAgent in the scratch org.
Share:

Action Plan in Financial Services Cloud || Winter '19 New Feature

In Winter '19 release, Salesforce introduced Action Plans for Financial Services Cloud. It captures repeatable tasks in templates and then automate the task sequences with an action plan.
Example: Processing Loan application, Customer on-boarding process etc. It will also give you the option to create reports and dashboards to monitor progress and ensure compliance.

It consists of three parts -
Action Plan Template: Power consistent customer experiences with configurable task templates.
Process Automation: Increase productivity by automatically generating tasks with due dates and role based assignment.
Plan Execution: Drive collaboration and complaint task completion with analytics and enforcement of required tasks.

Let's explain in details -

Action Plan Template

An action plan template is nothing but a list of tasks to complete a business process. In a template, each task is given a priority, the deadlines (the number of days in which it should be completed - data offset), and who is responsible. Then this action plan template is used to create action plans with each task assigned to a user with a completion date.

Below picture will give you a great view of Action Plan Template and Action Plan -

Now let's start creating one Action Plan:

Pre-requisite

  • Permission Set: You need to assign permission set - ActionPlans to the users. Without this permission set, you will not be able to assign action plan task to those users.
  • Extra Permission: You can provide below standard object permission so that users can edit and delete action plans-
    • Action Plan: Read, Create, Edit and Delete.
    • Action Plan Template: Read, Create, Edit, Delete and View All
  • Status Field Required: This is required to accurately track and report on action plans based on their status. Set the Action Plan Status as mandatory field in Action Plan layout.
  • Action Plan List to Account  Page Layout: Add action plan related list in Account Page layout.
  • Action Plan Lightning Component: Add the Action Plans List - Financial Services Cloud Lightning Component in the page in a separate tab.
  • Setup Nonwork days: Use this option to skip nonwork days when setting up the task completion dates. To do that, you can set the Business Hours and setup company-wide holidays.


Use Case

We will use Action Plan Template to automate new credit card opening processes for financial institute XYZ and then use the template to create the action plan for one of the account. 


Action Plan Template

Let's start by creating the action template and inside the action template below are the tasks -

Against each task, we have the option of whom to assign the task - we have three options (Action Plan creators, any other user, or the account team member role). We can define the number of days to complete the task and priority. Here is the view -

Finally we can publish the action plan template.


Action Plan

Now with action plan template published, we can login to any account and create the new plan using action plan template. Here is the action plan creation for - XYZ Visa Credit Card 


What happened at the backend, Salesforce has created all the tasks and assigned to owners based on the task configuration. We can see the same from account's task view.

Considerations




Share:

Apex Code to Assign Territories to Opportunities


Assigning Territories to Opportunities can be done manually, but there is an option by which you can automate this process. This blog post is all about writing Apex class to automate the Territory assignment to Opportunity record.

Before I start explaining the Apex code, let me explain two important objects -
  • Territory2Type: This represents the category of Territories(Territory2). Every territory must have a Territory2Type. The important field within this object is Priority, which is used in Opportunity filter to assign Territory to Opportunity.
  • ObjectTerritory2Association: This represents the association between Territory and Object record, which is Account. This is available only if Enterprise Territory Management is enabled.
The Apex code is written here in the Salesforce Developer's guide. 

The logic is as follows -
  • If the Opportunity's Account record is assigned to no Territory, then Opportunity's territory2Id field will be null.
  • If the Opportunity's Account record is assigned to 1 Territory, then Opportunity's territory2Id field will be assigned to same Territory record.
  • If the Opportunity's Account record is assigned to more than 1 Territories, then Opportunity's territory2Id field will be assigned to that territory record which is having highest priority.
    • If multiple territories are having the same priority, then Opportunity's territory2Id field will null.
Once you have the apex class written, you can configure the Opportunity Territory assignment filter by going into Setup -> Territory Settings and there providing the apex class name. The screenshot is given below -

Few important point to mention here -
  • The class OppTerrAssignDefaultLogicFilter is provided by Salesforce. But you can write your own class to implement logic as per your business need and use that. You need to make sure that you class is implementing TerritoryMgmt.OpportunityTerritory2AssignmentFilter interface.
  • This class will execute only for those Opportunities where IsExcludedFromTerritory2Filter = false. This is the field named as "Exclude from the territory assignment filter logic" found in Opportunity record. You need to include this field in Opportunity page layout to select/de-select. Otherwise you can use the api to set the value of field IsExcludedFromTerritory2Filter.
  • This apex class can work on maximum 1000 opportunities.


Share:

Using SalesforceDx deploy metadata in Sandboxes or Non-Scratch Salesforce Orgs


With the introduction of Salesforce DX, it creates confusion how can I work with old Salesforce(Non Salesforce DX) projects. In this post, I tried to explain how you can still work with your existing non salesforce dx project code, but get all the benefits of Salesforce DX.

First let's understand the biggest difference between Salesforce DX and Non Salesforce DX which is that in Salesforce DX we don't need any package.xml and all the changes will be automatically detected. Basically in Salesforce DX, the project format is different than traditional Non Salesforce DX project format.

In today's blog post, I will discuss how Salesforce DX can be used without enabling Developer Hub with normal Salesforce instance.

I will be using one my developer org(Non Salesforce DX) for this one.
The first command I will be issuing here is to authenticate my developer org and the command is:

sfdx force:auth:web:login -a SudiptaPersonal

Above command will open the browser where I will be providing my org's credential and thus authenticating my personal org. With -a, I am here giving alias "SudiptaPersonal" to my developer org. Advantage of setting alias is that going forward, I will be using alias to issue any commands against this org instead of typing username and password every time.

Now I will try to retrieve metadata using package.xml. For that, I stored the package.xml in src folder and now with the below command I will be able to retrieve metadata

sfdx force:mdapi:retrieve -k src/package.xml -u SudiptaPersonal -r ./sourceZip
  • -u:   I am using alias to execute this command against my Personal Salesforce Org.
  • -r:   This is the location where the zip file will be stored.
  • -k:  Location of the package.xml which will be used to retrieve the list of metadata.
Now let's try to deploy the metadata using Salesforce DX. I will be using below command to deploy metadata into regular Salesforce instance.
sfdx force:mdapi:deploy -f sourceZip/unpackaged.zip -u SudiptaPersonal -w 10 
  • -u:   I am using alias to execute this command against my Personal Salesforce Org.
  • -f:    Zip file location containing metadata and package.xml.
  • -w:  Wait time in minute for operation to complete.
Now I will show how you can convert old project structure to Salesforce DX format. For that, let's create a blank Salesforce DX project by using the below command -

sfdx force:project:create -n PersonalDXProject

Once the project is created, I will create two folders -
  • src:   This is the place where I will store package.xml
  • sourceInZip: This is the place where the metadata will be downloaded in zip format.
Here is the folder structure -

Next I will issue the below command to retrieve metadata :

sfdx force:mdapi:retrieve -u SudiptaPersonal -k src/package.xml -r sourceInZip
This will retrieve the metadata in zip format and store in the folder sourceInZip.


Now I will unzip the metadata and use the below command to convert the code base into Salesforce DX format -

sfdx force:mdapi:convert -r sourceInZip/unpackaged
  • -r:   Folder containing the unzipped source code
With this command, I will have all my code base converted into Salesforce DX format. Now I will execute the below command to convert Salesforce DX format codebase into Metadata API format so that it can be deployed into Non-Salesforce DX org. The command I will execute is:

sfdx force:source:convert -d convertedCode/ -r force-app/
  • -d: Folder where the converted code and package.xml will be stored.
  • -r: Folder containing the current Salesforce DX.
With code base converted, I will execute the below command to deploy this file in my non-salesforce dx org.

sfdx force:mdapi:deploy -u SudiptaPersonal -w 10 -d convertedCode

This process is required to deploy changes from Salesforce DX org(your development environment) to Non-Salesforce DX org (for example: QAT).

Here is the small video showing how to use Salesforce DX to retrieve, convert and deploy metadata into Non-Scratch Org.



Please provide your feedback.

Share:

Getting Started with Salesforce DX


What is Salesforce DX?
Salesforce DX is a way to shift your development lifecycle and to manage your source of truth. But don't consider Salesforce DX is going to do any magic, as a developer/release manager/lead you need to come up with your own strategy to manage your releases, other challenges like code conflict, urgent fix etc.

Why we need Salesforce DX?
I think the best way to answer this is with some real time scenarios.

Recently I was working with one of my customer who was having multiple sandboxes like DEV, SIT, QAT, UAT. A typical scenario. Now every time there was any kind of production issues, development team tried to find out the root cause and also tried to find out if the issue was due to some of the recent releases. But since all sandboxes were having the same code as Production, there was no way to find out previous code base. So in this situation normally developer request for a new sandbox with production code and fix the issue. This type of development is known as "Org Based Development".

But consider if the code was present in some source control repository then developer can easily get the previous code base, compare code between recent releases (basically comparing between master and branches). But does that really solve our problem? Somehow, but not fully. So basically we need to create an org from code present in source control repository(specifically from branches). Salesforce DX will provide us this option. This type of development is known as "Source Based Development".

Salesforce DX introduces a new type of org known as "Scratch Org" which can be created from source control repository.

What are Scratch Orgs?
Salesforce DX can be enabled for any Salesforce instance. They are known as Developer Hub. Winter'19 will provide us the option of enabling Salesforce DX even in developer org. From Developer Hub, we can create multiple scratch orgs. Scratch orgs are basically temporary org which can be created from source control repos and can be used to build some functionalities, perform proof of concept, test and finally create packages. Once done, developer can deploy the package into sandbox, push the code into repos and finally delete the scratch org.

Install Salesforce DX
Install Heroku CLI and then run the below command to install Salesforce CLI
heroku plugins:install salesforcedx

Prerequisite
We need one repository to work with Salesforce DX. We will work with the this repository. So let's start by cloning the repository.
git clone https://github.com/forcedotcom/sfdx-simple
cd sfdx-simple/
You will see the code is being checkout in your local machine with below folder structure



Authorize Salesforce DX to login into Developer Hub
Execute the below command which will authorize Salesforce DX to login into Developer Hub. -d will make this as  the default org and -a will set Sudipta as the alias for this org. Setting alias is really helpful to execute the command without typing the username every time.
sfdx force:auth:web:login -d -a Sudipta
Now if you execute the below command, you will be able to see the list of orgs authorized with Salesforce DX
sfdx force:org:list
Here is the result. See the alias in set as Sudipta. D indicates this is my default org and status is Connected.


Let's create Scratch Org
The important file to create scratch project-scratch-def.json file. It will be stored inside the config folder. This is the place where you will put the configuration of your scratch org. Here is the documentation which lists all the scratch org definition configuration values. In Winter'19, you can specify scratch org settings or org preferences in this file , but not both. Since Salesforce is going to deprecate support for org preferences in this file from Spring'19, it is recommended to convert org preferences to scratch org settings. How to convert is documented here.

Below command is going to create the scratch org. -d specifies with configuration file, -a sets the alias as FirstScratchOrg and -s is making this is as the default scratch org
sfdx force:org:create -f config/project-scratch-def.json -a FirstScratchOrg -s
You will be given below information


Now running the command will display DevHub and newly create scratch org as -


Open the Scratch Org
Below command will open the scratch org in browser. See the beauty of alias as you don't need to remember the username and password to login to your scratch org.
sfdx force:org:open -u FirstScratchOrg

Push code into Scratch Org
To push code into scratch org, you need to configure sfdx-project.json file. This is the file where you will define Namespace, Package Directories, API Version etc. Once defined, the below command will push the code from your local  machine to scratch org
sfdx force:source:push -u FirstScratchOrg
You will find the confirmation message like -


Find out the differences between Scratch Org and Local
Below command will show the differences between your scratch org and Local
sfdx force:source:status -u FirstScratchOrg
Now I have created one custom field in Account object, updated FLS in few profiles, added the field in page layouts. I also have made some changes in DemoController.cls in my local machine. So the above command will give me the below result. Important column is STATE which will indicate where the changes happened.


Pull Changes from Scratch Org:
Below command will pull changes from your scratch org
sfdx force:source:pull -u FirstScratchOrg
Here is the outcome -



Running Test Classes
Execute the below command to run test classes in your scratch org. This will provide the job id which you can use to fetch the report of your test execution

sfdx force:apex:test:run -u FirstScratchOrg
Here is the screenshot from my scratch org -


Generate Password for Scratch Org
Below command will generate the password for your scratch org.
sfdx force:user:password:generate -u FirstScratchOrg
You will  get a message -
Successfully set the password "P7(pD|ca57" for user test-imv1gedrvlxi@example.com.

In future if you want to know the password, execute the below command -

sfdx force:org:display -u FirstScratchOrg
It will provide many informations including password -


Deleting Scratch Org:
Once you are done with scratch org, you can delete the same with below command -
sfdx force:auth:logout -u FirstScratchOrg
Here is the message -






Share:

Getting Started with Financial Services Cloud


One of the biggest advantages of being a consultant is that you will be able to play with new technologies/functionalities because each customer comes up with their unique requirements. This is how I was introduced to Salesforce's Financial Services Cloud (also known as FSC) recently. Today I am going to explain basics of FSC and how you can start exploring it.

Salesforce's Financial Services Cloud is basically having the similar concept of Non-Profit starter pack. It will be a combination of managed and unmanaged packages installed to your org. Focus here is to support Financial Services sector. FSC is only available in Lightning Experience.

The heart of FSC is the managed package - "Financial Services Cloud". Along with this, you will get two more unmanaged packages - "Financial Services Ext" and "Financial Services Referral Ext". There is another very important managed package which will be kind of differentiator and that is none other than "Financial Services Cloud - Einstein Analytics". Note - This is true as of today (Winter 18 release).

FSC will allow companies like wealth management, investment firms, banks, asset managements and other financial institutions to manage their customers, along with their assets, liabilities, financial accounts, and much more. With this high level description why FSC, let's dig into more unique terminologies now.

BUILDING BLOCKS OF FSC
Let's start with Financial Services Cloud's building blocks - Clients and Relationship Groups/Households.

Clients - A client is anyone doing business with the advisor in the past, present or future. Clients include prospects, active or inactive clients, spouses, partners, and dependents. FSC implements clients in two different ways Individual or Person accounts. Don't worry, I am going to explain the differences between them very soon.

Relationship Groups/Households - A household represents a groups of clients and businesses whose financials are summarized at the group level. In FSC, each client or entity's role(s) within that household is tracked. With that financial for each client or entity who are part of the same household can be rolled up to the group level for an aggregate view.

DATA MODEL
Now Financial Services Cloud's data model is basically having two versions based on your org's requirement of managing individual accounts or person accounts.

Individual Model - This model uses the combination of standard Account and Contact object to represent a unified view of the customer.
In this model you should use Individual record type if the client is person, otherwise use Institutional record type when the client is business of institute.

Person Account Model - This model uses standard Account object to hold all the information about a person. 
In this model you should use Person record type if the client is person, otherwise use Institutional record type when the client is business of institute.

Now let me explain a little further. Below are the type of the accounts FSC represents -
Individual - This represents a person client. For example, if you are client of a financial planner or advisor or customer of a bank, then you are represented as Individual account.
Institution - This account record type represents business client. For example your employer.
Household - This record type is used to group multiple individual accounts under one roof. This is used to roll up their aggregated financial information at the group level. Consider this as your household where you have you, your wife, children all are individual accounts.
Business - This is the standard salesforce account record type.

FINANCIAL ACCOUNTS 
Financial Accounts tab under Individual or Institution record will show all the assets, accounts owned by the client.

Financial Summary at the beginning of the page will show roll up data of all the information in the Financial Account related list. It provides a quick overview of the client's financial picture.

RELATIONSHIPS
In Financial Industry, relationship is the key. It is very important to track every type of relationship between clients, non-clients. The Relationship tab will help advisors to understand how the clients and non-clients are related to each other.

As you see from the above picture, Rachel Adams is part of Adams Household as the Primary Member. Nigel Adams (Spouse) and Adams Charitable Trust (Trustee) is also part of the same household. At the same time Ivan M Kohl is also related to Adams Household as their lawyer.

There is rollup section below which is a snapshot of the household members and their relevant informations. So in a single snapshot, I can see relevant contact details, their last and next interaction.
That's a lot of backend processing. Thinking of how to do that. You know it's very easy. Clicking on +Add Relationship button will bring the below page where you can configure what to add, configure them as primary member/primary group, their role in this relationship, values to be considered during roll up etc.


GOALS
We all have our financial goals. In Financial industry it is very important that advisors help their customers to reach their goals.  FSC will allow advisors to track client's progress towards their goals. Here a typical goal looks like -

DATA MIGRATION
As FSC adds some extra complexity to the data model, so it is very important to understand the data model first before start migrating data into Salesforce FSC. Like for Individual records, one should create either Account or Contact record, but not both, otherwise it will create duplicate records.

STUDY RESOURCE
Trailhead should be the first stop for you. Below are the Trailhead modules you should explore -
IMPLEMENTATION RESOURCE


Share:

Kitchener Developer Group: Everything you need to know about Einstein Bots by Shruti Sridharan



Special thanks to our speaker, Shruti Sridharan, for sharing her knowledge on Einstein Bots. 
Here comes the presentation and recording.

Presentation:

Share:

Kitchener Developer Group Event: Building Lightning Apps by Daniel Peter

Thank you to our guest speaker, Daniel Peter, Salesforce MVP, for his presentation on Building Lightning Apps. Here comes the presentation and recording.

Presentation:


Recording:

https://www.youtube.com/watch?v=zRhXqWNN-AU
Share:

Switch Statement in Apex - Long Pending Must To Have Feature

Finally we have Switch statement in Apex. Like me, I am very much sure there are many developers who were waiting for this feature. Salesforce introduced Switch statement in Winter'18 release.

In this post I am going to share few important stuffs that developer should keep in mind while using Switch.

Let me start with a very basic example.

In the above code I am using Switch statement. But did you notice that Switch statement in Apex is little different than traditional Switch statement in Java or C programming language?

No Case Statement: We don't have case statement in Apex programming language. Reason behind is that Case is a sObject in Apex. That is why Salesforce is having when keyword.

No Break: In Apex, we don't have break statement like we used to have in C programming language. The reason is that in Apex, there is no fall-through. It means unlike C, the first executed branch will block any following branch in Switch statement. For example, if you execute the above code with parameter 'India', it will only print I am in India. It will not execute other System.Debug statements.

sObject support: Apart from standard String, Integer, Long support, Switch statement in Apex can support sObject as well. To illustrate that, consider the below use case -

When a Task is getting created, it can be associated with many sObjects like Account or Case. So based on the sObject with which the task is associated, let's print different statements.

Here is the trigger handler class using Switch statement -

I hope this short post will help you to understand how Switch statement works in Apex.
Share:

Kitchener User Group & Salesforce ApexHour Event: How Salesforce Query Optimizer works for LDV

Thanks to guest presenter @Jitendra Zaa (Technical Architect & MVP at BLUEWOLF, an IBM Company)  for his presentation on How Salesforce Query Optimizer works for Large Data Volume! on Kitchener User Group. If you missed this, make sure you watch the recording!

Recording:  https://youtu.be/FtfZV5uf9fg


Link to the Slides:  https://www.slideshare.net/AmitChaudhary112/salesforce-apex-hours-how-lightning-platform-query-optimizer-works-for-ldv
Share:

Follow Me

Enter your email address:

Delivered by FeedBurner

Labels

Salesforce (105) Apex (47) admin (27) visualforce (21) ADM (20) dev 501 (19) integration (18) learn salesforce (18) 501 (16) lightning (16) javascript (14) SOAP (13) tutorial (11) Certification. (10) Kitchener Developer Group (8) Certification (7) Trigger (7) security (7) test class (7) unit testing (7) Advanced Admin (6) Advanced Apex (6) Sharing and Visibility (6) design pattern (6) developer (6) report (6) salesforce release (6) service cloud (6) trailhead (6) Lightning Experience (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) formula (5) mobile (5) solution management (5) use case (5) JSON (4) Kitchener User Group (4) Lightning Web Component (4) Sales Cloud (4) Salesforce DX (4) Tips (4) WebSphere (4) best practice (4) cast iron (4) component (4) deployment (4) event (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) visual studio code (4) Architect (3) Live Chat (3) Online Event (3) Opportunity (3) Performance (3) Products (3) REST (3) Role (3) Salesforce Certification (3) Scratch Org (3) Study Notes. (3) Summer15 (3) Web Technology (3) automation tool (3) dynamic apex (3) license (3) map (3) mapbox (3) release (3) singleton (3) version controlling (3) Asynchronous callout (2) Aura Framework (2) Bulkify (2) Community (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) LWC (2) Lightning Design System (2) Lightning Feature (2) Live Agent (2) Metadata (2) PD II (2) Price Book (2) SOSL (2) Sharing (2) Spring 15 (2) Summer17 (2) Territory (2) VS Code (2) Virtual Event (2) ant (2) basic (2) chatter (2) coding (2) communication (2) configuration (2) console (2) controller (2) documentation (2) dreamforce (2) flow (2) git (2) jquery (2) logging (2) object (2) permission (2) process builder (2) salesforce1 (2) strategy (2) xml (2) Action Plan (1) Action Plan Template (1) Activity Timeline (1) Advanced Currency (1) Agent Productivity (1) Analytics (1) Apex Sharing (1) AppExchange (1) Arrow (1) Article (1) Asynchronous Apex (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) Compare (1) Confetti (1) Constructor (1) Contact Center (1) Continuation (1) Continuous Integration (1) Convert (1) Cookie (1) CumulusCI (1) Custom Metadata (1) Custom Object (1) Custom Permission (1) Customer (1) Dated Exchange Rate (1) Decorator Design Pattern (1) Dev Hub (1) Development (1) Diwali (1) EDA (1) ESLint (1) Education Cloud (1) Email (1) FSC (1) Function (1) Future (1) Global Gathering (1) Goals (1) Guest Access (1) Guest Profile (1) Guest User Sharing Rule (1) Guide (1) HEDA (1) Higher Education (1) Household (1) Husky (1) IDE (1) Ideas (1) Improvement (1) KPIs (1) Knowledge Management (1) Large Data Volume (1) LastModifiedDate (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) Permission Set (1) Person Account (1) Photo (1) Pipeline (1) Platform Developer I (1) Platform Developer II (1) Presentation (1) Prettier (1) Product Schedule (1) Profile (1) Promise (1) Prototype (1) Public Site (1) Query Plan (1) Queueable (1) QuickReference (1) Related records (1) Reports (1) Retrieve (1) Role Hierarchy (1) SAL (1) SFDX (1) Salesfor (1) Salesforce Advisor Link (1) Salesforce Labs (1) Salesforce Optimizer (1) SalesforceDx (1) Schedule (1) Session (1) Sharing Rule (1) Sharing Sets (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Spring 20 (1) Summer14 (1) Summer16 (1) Summer19 (1) Switch (1) SystemModStamp (1) Timeline (1) Unauthorized Access (1) User License (1) Users (1) Validation Rule (1) Web (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) csv (1) custom button (1) custom settings (1) customization (1) data loader (1) database (1) delegate Admin (1) describe (1) dom (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)

Popular Posts

Total Subscribers

Total Pageviews

Contact Me

Name

Email *

Message *