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.
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.
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?
Skinny tables can contain a maximum of 100 columns.
Skinny tables cannot contain fields from other objects.
Skinny tables are copied to your Full sandbox organization from Summer ’15 release.
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.
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
