Month: April 2017

Salesforce Lightning Time Ago

In this blog, I am going to explain the time ago lightning components. Time Ago is the feature that will allow displaying the dates in “time Ago “format. The Application which you are going to build with this blog is going to look like as show like below image. Opportunity table that contains the close date and created date will be displayed in the time ago format.

What you are going to do 

  • Opportunity Lightning Time Ago Application
  • Opportunity Time Ago Component
  •  Using Timeago.js in components

Prerequisite

  • My Domain Should is enabled.
  • bootstrap static resource. Static resource name “bootstrap”
  • time ago JavaScript static resource. Static resource name “timeago”

Step 1:  Creating “OpportunityTimeAgo” lightning APP.

This Application is the container to place the lightning Time ago components.

Go to Developer Console, Create a Lightning App bundle with name “OpportunityTimeAgo” and add the below code.

 . 

Step 2:  Creating Apex Class “OpportunityCls” 

Now you are going to create an Opportunity list Component which contains time ago feature. After that, we will be adding to the Above App

 

Step 3: Creating “OpportunityList” Component

This Component will fetch the List of opportunities and display it in table format

Add the Below logic to OpportunityListController.js

 

Code Highlights

  • Opportunities attributes have contained the list of Opportunities return from Apex Controller.
  • aura: handler that will be executed on the component initialization.

Adding OppotynityList Component  to OpportunityTimeAgo App .

go to Developer Console — > Open Lightning resource  “OpportunityTimeAgo” and add the OpportunityList component to it as shown below.

Step 4 : Creating “OpportunityListTimeAgo” Component

Create an OpportunityListTimeAgo Component with the below code. This Component will be displayed the date in time ago format.

Add below code to OpportunityListTimeAgoController.js

Code Highlights 

  •  OpportunityListTimeAgo Component have a attribute “timeAgo” which will be used to pass from the OpportunityList.cmp Component .
  • aura:handler used to convert the date into TimeAgo format .

Step 5 : Adding OpportunityListTimeAgo.cmp to OpportunityList.cmp 

add OpportunityListTimeAgo to the OpportunityList component as show below .

Github URL for Complete code: https://github.com/rajamohanvakati/Lightning-Time-Ago

Salesforce Skinny Tables

Introduction : 

Potentially most of the customers have the large amount of the data in salesforce tables, which may cause more processing time is, at least partly, dependent on how long it takes to scan the data especially when we are scanning on the relationships. So one way of improving performance is to trim up the Skinny table. Naturally, incremental processing is useful for these very large fact tables, but everything will go faster with Skinny tables.

What is the Skinny table?

A skinny table is a custom table in the Force.com platform that contains a subset of fields from a standard or custom base Salesforce object. Force.com can have multiple skinny tables, if needed, and maintains them under the hood.

 

Skinny Table to Speed up Account Queries

Do we need a Skinny table? 

Before deciding do we need the Skinny table or not, first, let’s understand how salesforce design the Standard database.Below Images how salesforce organizes the Account table under the hood.

From the user view, an account object is a single table. But internally salesforce stores in two different table for an Account. One table for account standard fields and one table Account custom field which is partitioned rather than a single table. When end-user query the account table salesforce will perform the join on both the tables to return the data, which is little overhead if you have the huge amount of records. In this case, you can contact salesforce to create Skinny tables which will return more rows per fetch.

When to Use?

Skinny tables are most useful with tables containing millions of records. They can be created on custom objects, and on Account, Contact, Opportunity, Lead, and Case objects. In addition, they can enhance performance for reports, list views, and SOQL. The skinny table allows you to reorganize selected columns and rows of data into a separate table.

Any Considerations?

  • Contact Salesforce to create Skinny tables
  • Used to fetch frequently used fields and to avoid joins.
  • Skinny tables are most useful with tables containing millions of records.
  • Skinny tables can contain these types of fields.  Checkbox,  Date, Date and time, Email, Number, Percent, Phone picklist, Picklist (multi-select), Text, Text area, Text area (long), URL
  • skinny tables do not include soft-deleted rows (i.e., records in the Recycle Bin with isDeleted = true),
  • The Force.com platform automatically synchronizes the rows between the base object and the skinny table, so the data is always kept current.

Any Impact?

  1.  Skinny tables can contain a maximum of 100 columns.
  2.  Skinny tables cannot contain fields from other objects.
  3.  Skinny tables are copied to your Full sandbox organization from Summer ’15 release.
  4.    Skinny tables are custom tables in the underlying Force.com database. They don’t have the dynamic metadata flexibility you find in the base object. If you alter a field type (e.g., change a number field to a text field) the skinny table becomes invalid, and you must contact salesforce.com Customer Support to create a new skinny table.

Data.com Duplicate Management

Introduction 

Maintaining clean and accurate data is one of the most challenging things to improve productivity.  With new Salesforce data.com  matching rules and duplicate rules you can able to manage the duplicate records Data.com Duplicate Management to control whether and when users can create duplicate records in Salesforce.

How does Data.com Duplicate management work?

Data.com duplicate management working in two different ways based on when user trying to save the new records and when trying to save the edited records.

If new records 

When a user attempts to save a new record, the record is first compared with existing Salesforce records to identify possible duplicates

(1). The criteria used to compare records and identify the possible duplicates are defined by a matching rule. Next, a list of possible duplicates is returned

(2). What happens when the record being saved is identified as a possible duplicate depends on what’s defined in the duplicate rule

(3). For example, the duplicate rule could block users from saving the possible duplicate record or allow them to save it anyway.

Both the Block and Allow options include an alert, which tells users why they can’t save the record and what they need to do. The Allow option includes the ability to report on the duplicate records.

If editing the existing records 

When a user attempts to save an edited record, the record is first checked to see if the user has changed the value of a matching rule field. If so, the duplicate management process works as described for new records. If not, no further action is taken and duplicates are not detected.

Setting Data.com Duplicate Management

Setting duplicate management is contained in two steps. Setting up the Duplicate rule and Setting up matching rules.

Matching Rules

Matching Rules Matching rules are used to identify duplicate records within Salesforce.

A matching rule is made up of individual fields that are assembled into an equation. each field contains matching criteria that tell the rule how to compare the fields and what conditions need to be met for the specific field to be considered a match

Go to ->Setup ->data.com Administration-> Matching Rules –> new

 

Save the matching rule and activate.

 

The matching rule contains the matching criteria to identify the duplicate cases. Now let’s create a duplicate rule to map the Matching rule.

Duplicate Rules 

Duplicate rules are used to control whether and when you can save duplicate records within Salesforce. Duplicate rules tell Salesforce what action to take when you attempt to create a duplicate record. Each duplicate rule requires at least one matching rule to identify which existing records are possible duplicates. You can configure your duplicate rule to do something when a record is created and edited. However, the rule only runs for edited records if the fields being edited are included in the associated matching rule

The duplicate rule can block you from saving records that have been identified as possible duplicates or allow them to save them anyway. Both the Block and Allow options include an alert, which tells you why you can’t save the record and what you need to do. The Allow option includes the ability to report on the duplicate records

Go to ->Setup ->data.com Administration-> Duplicate Rules –> new .

After saving you can see

Record level Sharing  on Duplicate Rule  

Record level sharing indicated whether you wanted to enforce them to check the user sharing on data while performing the duplicate check. if you select  “By Pass Sharing rule “ duplicate rule will check at the org level. If you select the  “Enforce Sharing rules” it will check only on user data, not on org.

Actions:-  

The duplicate action is specified on which actions should run on Duplicate record. It can be ” allow ” or “block “

Based on the business decision you can allow the user to create a duplicate record or block them . when you need to allow you have an options show the alert text with the details

Alert Text:-

Alter text will give the details message to the user why he is not able to save the record.

Putting  in action 

Now, let’s test the duplicate management process by creating a new account.

When you create a new account that matching with matching rule Salesforce will throw an error message as shown below. Based on your data.com duplicate rules you can take the action . in this case we set the “Allow” on creating a with “Alert ” So we can then save the record by ignoring the alert message

 

Duplicate Record Sets

Duplicate Record Sets tab is the place when you can find all the duplicate records alone with the duplicate Rule which caused to create the record.

 

Duplicate record sets and duplicate record items can be used to do the following.

  • Create custom report types
  • Create custom fields
  • Write validation rules, triggers, and workflow rules
  • Modify the fields that can appear on the respective page layouts