Salesforce API

Salesforce provides a WSDL (Web Service Description Language) files. They are called “Enterprise WSDL” and “Partner WSDL”. A WSDL is an XML-document which contains a standardized description on how to communicate using a web service (the Salesforce API is exposed as a web service). The WSDL is used by developers to aid in the creation of Salesforce integration pieces. A typical process involves using the Development Environment (eg, Eclipse for Java, or Visual Studio for .Net) to consume the WSDL, and generate classes which are then referenced in the integration.

The primary differences between the two WSDL that we provide are:

Enterprise WSDL:
a) The Enterprise WSDL is strongly typed.
b) The Enterprise WSDL is tied (bound) to a specific configuration of Salesforce (ie. a specific organization’s Salesforce configuration).
c) The Enterprise WSDL changes if modifications (e.g custom fields or custom objects) are made to an organization’s Salesforce configuration.

For the reasons outlined above, the Enterprise WSDL is intended primarily for Customers.

Partner WSDL:
a) The Partner WSDL is loosely typed.
b) The Partner WSDL can be used to reflect against/interrogate any configuration of Salesforce (ie. any organization’s Salesforce configuration).
c) The Partner WSDL is static, and hence does not change if modifications are made to an organization’s Salesforce configuration.

For the reasons outlined above, the Partner WSDL is intended primarily for Partners.

Permanent link to this article: https://salesforcebuddy.com/2019/02/salesforce-api/

Working with Record Types

Get Record Type Id by Developer Name

Salesforce has finally provided us with a way to easily get Record Type Id by Developer Name, without using a SOQL query. This new feature comes with Summer ‘18 Release and it should help us write more efficient and reliable code.

The old way

Let’s imagine that we have a Record Type on Account object called “Wholesale Partner”. We would like to obtain the Id of this Record Type in order to assign it to the RecordTypeId field on the Account record during the insert operation.

Previously, there were a couple of options to obtain a Record Type Id in order to assign it to a record, but none of them were really optimal. One approach was to use the Record Type Name in order to obtain a Record Type Id in the following way by using the getRecordTypeInfosByName() method of the DescribeSObjectResult class:

Id recordTypeId =
  Schema.SObjectType.Account.getRecordTypeInfosByName()
    .get('Wholesale Partner').getRecordTypeId();

The issue here is that the Record Type Name is nothing but a label, which can be easily changed by an administrator in Production, thus breaking your code without any warning. The second issue with this approach is that the logic might break in multi-language environments in case somebody translates the label. However, as far as I know, this was the only approach to obtain a Record Type Id without issuing a SOQL query.

This brings us to the second approach that uses the RecordType object. You can execute a SOQL query against this object to get the Record Type Id by Developer Name, which is much more stable than the label, it isn’t affected by translations, and cannot be changed that easily.

Id recordTypeId =
  [SELECT Id FROM RecordType
    WHERE DeveloperName = 'Wholesale_Partner' AND sObjectType = 'Account'].Id;

Although this approach is more reliable than the first, my issue with it is that it requires a SOQL query. In an environment that limits you to 100 SOQL queries per transaction, every one of them counts.

The new way

With Summer ‘18 Release we now finally have a way to use the Developer Name to obtain a Record Type Id without issuing a SOQL query. This is achieved by using the new getRecordTypeInfosByDeveloperName() method of the DescribeSObjectResult class:

Id recordTypeId =
  Schema.SObjectType.Account.getRecordTypeInfosByDeveloperName()
    .get('Wholesale_Partner').getRecordTypeId();

In my opinion, this should be a new standard for this kind of tasks, it’s both reliable and cheap on the resources. And if you are really concerned with resources and your logic requires to get Ids of different Record Types during execution, you should maybe consider caching the Map<String, Schema.RecordTypeInfo> returned by the getRecordTypeInfosByDeveloperName() method. If you are interested you can check out this answer on StackExchange with analysis on the resource consumption by different Apex Describe calls.

In case you want to use the above sample in your code, you should replace the Account with the object that has your Record Type, and the Wholesale_Partner with the actual Developer Name of the Record Type that you need.

How to assign a Record Type Id to a Record

So now that you have a Record Type Id, you can assign it to a specific record by using the RecordTypeId field. Here’s an example for Account:

Account acc = new Account(Name='Test Account', RecordTypeId = recordTypeId);

or through a property like this:

acc.RecordTypeId = recordTypeId;

Permanent link to this article: https://salesforcebuddy.com/2019/01/working-with-record-types/

Salesforce: Cross-Object Formulas

Cross-object formulas are formulas that span two related objects and reference merge fields on those objects. Cross-object formulas can reference merge fields from a master (“parent”) object if an object is on the detail side of a master-detail relationship. Cross-object formulas also work with lookup relationships.

To create a cross-object formula when building a formula, enter the relationship names of the objects to which you are spanning followed by the field you want to reference. Separate the relationship names of each object and the field with periods.

For example, enter Contact.Account.Name to reference the Account Name for a contact associated with a case in a formula field on the Case object. Be sure to use the relationship names of the objects, not the labels. Although the relationship name is often the same as the object name, it is technically the field name of the relationship field.

To reference the parent account name from Account object, the syntax is Parent.Name, not Account.Name. When referencing a custom object, add two underscores and the letter r to its name. For example, Position__r.title__creferences the Job Title field (title__c) on a Position custom object.

You can reference fields from objects that are up to 10 relationships away. Cross-object formulas are available anywhere formulas are used except when creating default values.

If you create a formula that references a field on another object, users can see the field on the object even if they don’t have access to that object record. For example, if you create a formula field on the Case object that references an account field, users can see this field even if they don’t have access to the account record.

Below are some Tips
Formula fields can expose data that user do not have access, such as:
– user do not have access to the field level security within the same object
– cross-object where user do not have access to the record- cross-object where user do not have access to the record and the field- cross-object where user do not have permission to the object

Roll-Up Summary Field
If a roll-up summary field doesn’t contain cross-object field references or functions that derive values on the fly, such as NOW or TODAY, it can calculate the values of formula fields.

Permanent link to this article: https://salesforcebuddy.com/2019/01/salesforce-cross-object-formulas/