Monday, August 31, 2015

What's the Real Risk with Enabling Divisions?

In Salesforce, divisions are a means to improve query and search performance by partitioning data into logical buckets called "divisions". However, like with the Person Accounts feature, many admins may hesitate and think twice about enabling divisions due to this warning: "Enabling divisions is irreversible. After implementing divisions, you cannot revert back to a state that does not have division fields."

"Irreversible", huh? Well... what's the real risk with enabling divisions? I think there is no significant risk.

According to Salesforce Help (Summer '15), enabling divisions may affect (or not) nine key areas. But it seems like the effects can be easily negated or suppressed.

Area Reversal Strategy
SearchRevoke the "Affected by Divisions" permission.
List viewsRevoke the "Affected by Divisions" permission.
ChatterNot supported (i.e., affected).
ReportsRevoke the "Affected by Divisions" permission.
Viewing records and related listsNot affected.
Creating new recordsSet to the global division.
Editing recordsSet to the global division.
Custom objectsSet to the global division.
RelationshipsSet to the global division.

In short, if you want to give divisions a try, talk to a few people about enabling the feature. If the foremost argument against enabling divisions is simply that it's irreversible, go ahead and just enable it anyway (in a full sandbox first). If it doesn't work for you, you can always revoke the Affected by Divisions permission from all users.

Tuesday, August 25, 2015

Salesforce API Versions

In Salesforce, did you know that API version 34.0 corresponds to Summer '15? Or that API version 17.0 means Winter '10? If not, this simple table of API versions and release names may be useful to you.

API VersionRelease
34.0Summer '15
33.0Spring '15
32.0Winter '15
31.0Summer '14
30.0Spring '14
29.0Winter '14
28.0Summer '13
27.0Spring '13
26.0Winter '13
25.0Summer '12
24.0Spring '12
23.0Winter '12
22.0Summer '11
21.0Spring '11
20.0Winter '11
19.0Summer '10
18.0Spring '10
17.0Winter '10
16.0Summer '09
15.0Spring '09
14.0Winter '09
13.0Summer '08
12.0Spring '08
11.0Winter '08
10.0Summer '07

Friday, August 14, 2015

6 Salesforce Target Attributes Every PowerCenter Session Should Set

When using Informatica PowerCenter to perform ETL jobs that process large data volumes (think millions of records), there are at least six attributes that should be set for each session. And even when loading smaller data volumes, these attributes may still be worth setting to improve performance.

1. Max batch size = 10000


The assumption here is that the session will use the Bulk API, which is the fastest way to load data in Salesforce. Period. As of Summer '15, the maximum batch size for a Bulk API job is still 10,000 records. Let's take advantage of this.

2. Set fields to NULL = checked


With data loads, by default it's best to assume that a blank field means that there is no data from the source system to feed this field. In this case, whatever is currently in the field would be considered invalid, to be overwritten with a blank value during the feed.

3. Use SFDC Bulk API = checked


Self-explanatory.

4. Monitor Bulk Job Until All Batches Processed = checked


When chaining tasks inside a worklet or workflow, monitoring the bulk job until all batches are processed helps to ensure that a dependent task will start only after the predecessor task truly completes. Otherwise, not only would you increase the risk of encountering locking errors, you run the risk of the next task running in the context of stale data.

5. Enable field truncation attribute = unchecked


This is equivalent to the Allow field truncation setting in Salesforce Data Loader. Unfortunately still, as of Summer '15, using the Bulk API prevents us from using this automatic truncation option. So you should be aware that truncating values must be done by other means during the transformation, not the load!

6.Enable hard deletes for BULK API = checked


Why not? This significantly improves the performance of mass delete operations, by skipping the Recycle Bin and erasing the record immediately.