Saturday, December 3, 2016

Salesforce: Deployment Test Levels

To deploy components from to Sandbox, or to Production via Change Set or other tools, Salesforce will offer option of test level to execute, even you just would like to validate the Change Set. I think most of admin will select Default when asked to select an option to Validate or Deploy, which is okay.

So, what is Default here mean?
If you deploy to production environment, all local tests are executed if your change set contains Apex classes or triggers. If your package doesn’t contain Apex components, no tests are run.
For deployment to development environments, such as sandbox, Developer Edition, or trial orgs, no tests are run by default.

What is the other options?

Run local tests
All tests in your org are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.

Run all tests
All tests in your org are run, including tests of managed packages.

Run specified tests
Only the tests that you specify are run. Choose the test classes that provide sufficient coverage for the classes and triggers being deployed. Provide the names of test classes in a comma-separated list.

Code coverage requirements differ from the default coverage requirements when using this level in production. The executed tests must cover the deployed class or trigger with a minimum of 75% code coverage. This coverage is computed for each class or trigger individually and is different from the overall coverage percentage.

Developer ideally do not have access to Production org. When deploy components with apex class or trigger, by default deployment from a sandbox to other sandbox will not execute any tests. Only when it reach deployment to Production, by default it will execute all local test and you can't skip it.

When you have major deployment, it is recommended to select test level Run local tests when you deploy within sandboxes, this will lets you catch and fix issues before the customization are rolled out to production on a targeted deployment date.

Below sample of change set deployment contains apex class and trigger, then we validate in another sandbox.

this screenshot taken when deploy to sandbox and select Default test option

this is the same change set, but with option Run local test


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, but you do not need to have 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

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

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.


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.


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


Saturday, November 5, 2016

Salesforce: Child Implicit Sharing

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

Child Implicit Sharing is ability for Account owner to access child records (contacts, opportunities, and cases), even now owned by 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 Account owner in the role hierarchy.

Above screenshot 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 - Account owner will have full access of the Contact, even the Contact is owned by other user.

Object (contact, opportunity, and case) with sharing "Public Read/Write" will be also not shown here, because all user 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 applications. This kind of 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 application. In other words, this isn't a configurable setting; 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 Opportunities, Cases, or Contacts for that account. This also meant when user have access to record from other object (NOT opportunity, case, or contact) that lookup to an 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.