A blog dedicated to Salesforce Ohana

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:

Follow Me

Enter your email address:

Delivered by FeedBurner

Popular Posts

Labels

Salesforce (105) Apex (44) admin (27) ADM (20) visualforce (20) dev 501 (19) integration (18) learn salesforce (18) 501 (16) SOAP (13) lightning (12) tutorial (11) Certification. (9) javascript (8) Trigger (7) test class (7) unit testing (7) Sharing and Visibility (6) design pattern (6) report (6) security (6) trailhead (6) Advanced Admin (5) Certification (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) developer (5) formula (5) mobile (5) salesforce release (5) service cloud (5) solution management (5) use case (5) JSON (4) Kitchener Developer Group (4) Lightning Experience (4) WebSphere (4) best practice (4) cast iron (4) component (4) deployment (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) Advanced Apex (3) Architect (3) Live Chat (3) Performance (3) Products (3) Role (3) Sales Cloud (3) Salesforce DX (3) Scratch Org (3) Study Notes. (3) Summer15 (3) Tips (3) Web Technology (3) dynamic apex (3) event (3) license (3) map (3) mapbox (3) singleton (3) version controlling (3) Bulkify (2) Data Architecture and Management Certification (2) 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) Lightning Design System (2) Live Agent (2) Metadata (2) Online Event (2) Opportunity (2) Price Book (2) REST (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) Agent Productivity (1) Analytics (1) Apex Sharing (1) Arrow (1) Asynchronous callout (1) Aura Framework (1) Bots (1) Browser (1) Bulk data load (1) CTA (1) Calendar (1) Canon (1) Case Management (1) Cheat Sheet (1) Classic (1) Community (1) Constructor (1) Contact Center (1) Continuation (1) Continuous Integration (1) Convert (1) Cookie (1) Custom Metadata (1) Custom Object (1) Customer (1) Decorator Design Pattern (1) Dev Hub (1) Devops (1) Diwali (1) Email (1) FSC (1) Function (1) Goals (1) Guide (1) Household (1) Ideas (1) Improvement (1) KPIs (1) Kitchener User Group (1) Large Data Volume (1) LastModifiedDate (1) Lightning Web Component (1) Manual Sharing (1) Metrics (1) New (1) OOPS (1) OWD (1) Omni-Channel (1) Partner (1) Person Account (1) Photo (1) Platform Developer I (1) Presentation (1) Product Schedule (1) Profile (1) Promise (1) Prototype (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Retrieve (1) Role Hierarchy (1) SFDX (1) Salesforce Optimizer (1) Session (1) Sharing Rule (1) Sharing Sets (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) Switch (1) SystemModStamp (1) User License (1) Users (1) Webservice (1) Winter'15 (1) Winter'17 (1) access (1) agile (1) app (1) approval process (1) aura (1) awesome (1) backup (1) bitbucket (1) book (1) campaign (1) change set (1) code (1) code coverage (1) configuration (1) csv (1) custom button (1) custom settings (1) customization (1) data loader (1) database (1) delegate Admin (1) describe (1) dom (1) dreamforce (1) duplicate (1) dynamic (1) equals (1) error (1) field-level security (1) folder (1) ftp (1) generic (1) gift (1) global describe (1) hashcode (1) import wizard (1) jenkins (1) keynote (1) long running requests (1) monitoring (1) mysql (1) 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