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:

• SimplySfdc: Duplicate Management
• Duplicate Management (Generally Available)
• Searching for duplicates across all objects
• Create Custom Report Types for Duplicate Record Reports

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:

• Miscellaneous Sample Validation Rules
• Formula Operators and Functions I–Z
• Regex Pal
• RegExr

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:

• File Sharing Settings and Permissions
• Content Architecture
• ContentDocument

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 to users above the Account owner in the role hierarchy.

The above screenshot is taken from org. with all contact, opportunity, and case sharing settings "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 also not be shown here, because all users have permission to read and edit the records.

Since the Winter '24 release, salesforce introduced Faster Account Sharing Recalculation, where the sharing access is not stored in CaseShare, ContactShare, or OpportunityShare object, but is determined when the user accesses the record; query to those objects will return zero records. You can use UserRecordAccess or look at the AccountShare to determine access.

Reference:

• Faster Account Sharing Recalculation
• Faster Account Sharing Recalculation in Salesforce

Salesforce: Parent Implicit Sharing

In addition to the sharing setting defined by the system admin, the Salesforce platform also has built-in sharing behaviors between parent and child records. This sharing is called implicit sharing because it is not configured by administrators but defined and maintained by the platform.

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

Parent implicit sharing provides read-only access to parent record (Account) when the user has read/write or read-only access in a child record (Opportunity, Case, or Contact) through child record ownership, sharing rule, or added as a team member (Opportunity Team or Case Team). 

For example, Account A has 3 contacts; if user X has access to one (or more) of the contacts of Account A, user X will be able to access the Account as read-only.

If the user has access to the child record via object permission (in Profile or Permission Set), the parent implicit sharing does not apply.

Parent implicit sharing only gives read-only access to the Account; for example, if A is the owner of an opportunity, parent implicit sharing will not give A access to ALL Contacts and Opportunities under the same Account.

Opportunity Contact Role

Parent implicit sharing does not apply by adding Contact Roles in the Opportunity. Adding Contact Roles to the Opportunity will not allow the Contact owner to have access to the Account.

Related Contacts

Parent implicit sharing does not apply by adding Contact as a Related Contact to an Account (indirect). Adding a contact as a Related Contact will not allow the Contact owner to have access to the Account.

Lookup Relationship
When the user has access to a record from other objects (NOT Opportunity, Case, or Contact) with a Lookup relationship to the Account, the user will see the Account Name only, but not the Account detail—this includes Account lookup to the Parent Account; the child account owner will see the Parent Account Name only.

The same behavior applies to lookup from other objects, including custom objects. For the Master-Detail relationship, the child record does not have an owner, so it is not applicable in this scenario.


If we look from the back end at how this is stored, there is an object called AccountShare. This object stores all the defined and implicit sharing. It also has RowCause, which tells us the reason that this sharing entry exists.

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

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

Reference:

• Implicit Sharing
• Built-in Sharing Behavior
• AccountShare 
• Salesforce: Child Implicit Sharing
• A Guide to Sharing Architecture
• Performance Tuning for Visualforce and Apex

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:

• Using a colon in the Report Name
• When to Use a Colon: 9 Simple Rules