Pages

Tuesday, November 22, 2016

Salesforce: Duplicate Management on Cross Object Duplicate Rules

Ten months ago, I blog about standard Salesforce Duplicate Management feature. This is standard feature under Data.com, but you do not need to have Data.com license to use this.

In this blog, I would like to share more about Duplicate Management on Cross Object Duplicate Rules.
Example: Email should be unique across Contact and Lead. While within the Contact and Lead itself, there are also other parameters that consider as duplicate in both Lead or Contact.

Lead duplicate matching rule:
- First Name + Last Name + Company
- Email

Contact duplicate matching rule:
- First Name + Last Name + Account
- Email

Solution:
1. Two matching rules in both Contact and in Lead

Contact: to match First Name + Last Name + Company OR Email

Lead: to match First Name + Last Name + Account OR Email

Contact: to match Email only for Lead cross object check

Lead: to match Email only for Contact cross object check


2. One duplicate rule in both Contact and in Lead

Contact duplicate rule, only can add one matching from each object


Lead duplicate rule


Note:
When edit record, Duplicate Rule will kick-in only when you update field related to fields defined in Matching Rule.

In this sample I select Fuzzy for the matching rule for First Name and Last Name, for example: Bob and Robert is considered as duplicate. But since we configure with "Allow" on create or edit, it will allow user to Save (Ignore Alert), but we can report on this with custom report type.




Reference:



Friday, November 18, 2016

Salesforce: Regex allow only Numbers and Special Character


Phone field in Salesforce by default will accept any characters with maximum of 40 characters. Because of this flexibility, user can enter any data and cause the data become dirty.

Requirement: to allow only numbers, space, and special characters + ( ) . - / in phone, fax, mobile field.

Solution: use Regex in Validation Rules

NOT ISBLANK( Phone ) && 
NOT(REGEX( Phone, "^(?=.*?[1-9])[0-9()/\\-\\+\\s\\.]+$"))


Regular expression syntax is based on Java Platform SE 6 syntax. However, backslash characters (\) must be changed to double backslashes (\\) because backslash is an escape character in Salesforce.


Reference:

Sunday, November 6, 2016

Salesforce Files Type and Sharing

"Files" in Salesforce introduce after Attachment and Document. They are not related each other. However, Files is related to Library, they support content search, while Attachment and Document are not. When you upload a file to library, the same file will be available in "Files" tab as well.

Here are few type on how the Files loaded and the differences:

1. Upload file directly to Files tab

2. Contribute file to Private Library

3. Contribute file to Shared Library

4. Upload file from Chatter record feed, or user feed, or Chatter group


If you click "Go to Content Detail Page", here is the differences:

1. Upload file directly to Files tab

2. Contribute file to Private Library

3. Contribute file to Shared Library

4. Upload file from Chatter record feed, or user feed, or Chatter group


We discussed about Content Architecture sometimes back, Files API is called ContentDocument start with prefix 069, while Library API is called ContentWorkspace start with prefix 058.

Let's query and see what is the difference from the backend
SELECT Id,ContentSize,FileExtension,FileType,ParentId,PublishStatus,Title FROM ContentDocument WHERE Id IN ('0693B00000083pw','0693B00000083q1','0693B00000083q6','0693B00000083qG') ORDER BY Title


- ParentId is refer to Library only - private library, record feed or chatter group is Not count.
- PublishStatus: P = Public, R = Private


Reference:


Saturday, November 5, 2016

Salesforce: Child Implicit Sharing

In the previous blog, we discussed Parent Implicit Sharing, let's discuss Child Implicit Sharing now.

Child Implicit Sharing is the ability of the Account owner, even if the user does not have access to the child record as defined in that child record.

Child Implicit Sharing also applies to the Account team, if the user is added as an account team member and given access to relevant child access (contacts, opportunities, and cases).



Querying the child Share object, such as OpportunityShare, you will see the RowCause as ImplicitChild.

Example: SELECT Id, UserOrGroupId, OpportunityAccessLevel, RowCause FROM OpportunityShare WHERE UserOrGroupId = '00580000001ren7AAA' AND OpportunityId = '0062H00001ESrWYQA1'



For the account owner, the account owner's role determines the level of access to child records (read-only or read/write). The same scenario is also applicable for users above the Account owner in the role hierarchy.


The above screenshot is taken from org. with all contact, opportunity, and case sharing setting is "Private". If Contact sharing is "Controlled by Parent", you will not see Contact access here - the account owner will have full access to the Contact, even if the Contact is owned by another user.

Object (contact, opportunity, and case) with sharing "Public Read/Write" will be also not shown here, because all users have permission to read and edit the records.



Friday, November 4, 2016

Salesforce: Parent Implicit Sharing


In addition to sharing setting defined by system admin, there are a number of sharing behaviors that are built into Salesforce platform. This sharing is called implicit sharing, because it is not configured by administrators; it is defined and maintained by the system.

Implicit sharing is automatic. You can neither turn it off, nor turn it on — it is native to the platform. In other words, this isn't a configurable, however, it's very important to understand.

Parent implicit sharing provide read-only access to parent records (Account only), when user has access to children record, such as: Opportunities, Cases, or Contacts for that account. This does not mean the user must be the record owned of the child record.

When user have access to a record from other objects (NOT opportunity, case, or contact) that have lookup to Account, user will see the Account Name only, but not to access Account detail - this include Account lookup to the Parent Account, child account owner will see Parent Account Name only.


The same behavior apply when lookup from other objects, including custom object.

If we are looking from the back-end on how this stored, there is an object called AccountShare, this object store all sharing defined and implicit sharing, it also have RowCause which tell us the reason that this sharing entry exists.

One of the value is ImplicitParent — the User or Group has access because they’re the owner of or have sharing access to records related to the account, such as opportunities, cases, contacts, contracts, or orders -- so, it is not always the records owner, but as long as the user have access to the child records.

sample query: SELECT Id, AccountId, UserOrGroupId, AccountAccessLevel, CaseAccessLevel, ContactAccessLevel, OpportunityAccessLevel, RowCause FROM AccountShare WHERE UserOrGroupId = '0053400000AAkhz' AND AccountId = '0013400001RhrP3'




Reference:



Wednesday, November 2, 2016

Salesforce: Use Colon for Report name


This tip is a quote from Salesforce success community #TipsTuesday "Using a colon in a report name places text before the colon on one line and text after the colon on another. This looks nicer and keeps reports with different names that need to be together, sorted together."

To keep this awesome tips, I share the tip with everyone from my blog and not buried in the forest of success community.

Here is normal Salesforce report naming.



When we add: in the report name, this is how it looks like when you or your user run the report, notice the different.



Let's look how we save it from Report Properties.



Note:
- this tip is not applicable to Dashboard.
- this also do not work in Lightning report


Last updated: 8 May 2017


Reference:


Page-level ad