Checkbox field for Live Agent pre-chat form

A [simple question](http://salesforce.stackexchange.com/questions/58529/live-agent-pre-chat-api-custom-checkbox-field/58533#58533) on Salesforce Stack Exchange exposed some unexpected behavior with the Pre-Chat API: Checkbox fields cannot be included as part of the pre-chat form.

The behavior appears to be that if a checkbox field is added to the specification for liveagent.prechat.findorcreate.map and liveagent.prechat.findorcreate.map.doCreate, the creation process fails and the desired record is not created. As soon as the checkbox field is removed from the form definition, the record creation process executes as expected.

While the reason for this behavior is unclear, at least there are two possible workarounds. The key to both workarounds is knowing that the String value of a marked checkbox is "on", and the String value of an unmarked checkbox is blank or null.

Workaround 1: Workflow rule

Assuming you've already created your Checkbox field, you can create a complementary Text field to hold the checkbox value submitted through the pre-chat form. For example, let's say your Checkbox field is named IsEmployed__c. You can create a Text field named IsEmployedText__c, and bind the pre-chat form field to IsEmployedText__c.

To close the loop, you'll create a workflow rule that basically sets IsEmployed__c to true when IsEmployedText__c equals "on", and another workflow rule to set IsEmployed__c to false otherwise.

Workaround 2: Formula field

Start with a Text field, and then simply create a Formula (Checkbox) field that uses NOT( ISBLANK( __ ) ) to produce the equivalent Boolean value.

For example, create a Text field named IsEmployedText__c, and bind the pre-chat form to this field. Within Salesforce, create a Formula (Checkbox) field named IsEmployed__c, and put int he formula NOT( ISBLANK( IsEmployedText__c ) ).

Auto External ID for Multi-Partner Integrations

Some companies need to integrate with multiple partner systems, each having its own set of unique identifiers. When you only have one or two of these external identifiers to manage, you can get away with setting up system-specific External ID fields. But happens when you trying to integrate with more than two such systems?

To make things worse, sometimes you have legacy ERP systems (e.g., in the higher education industry) that don’t have unique identifiers stored in a single field. Instead they use inferred keys derived from combinations of other fields.

In lieu of implementing a full MDM solution, one option to easily set up and manage these external identifiers can be to create just three components in Salesforce for each object: two fields and a workflow rule.

Auto External ID

The Auto External ID field is a Formula (Text) field that produces the string that represents the expected, globally unique external identifier. For example, the field could be a concatenation of two other values that produces something like “001154-900100203”.

Having this field also enables administrators to easily troubleshoot problems with the External ID value by comparing the expected identifier with the actual identifier.

{!ObjectLabel} External ID

The {!ObjectLabel} External ID field is a simple Text field configured to be a unique external identifier. The intent is that the Auto External ID value will always be stored in this field, so that DML operations via API’s can match on this field.

The {!ObjectLabel} part of this is simply a recommended labeling convention that helps your field look more like an out-of-the-box Salesforce field.

Set {!ObjectLabel} External ID

Finally, the Set {!ObjectLabel} External ID workflow rule should be configured to fire only when the Auto External ID and the actual External ID values do not match. This way, you avoid having a workflow rule that continuously edits a field blindly even when there is no need to update the field.

The workflow rule makes use of a simple field update that just sets the External ID field to the Auto External ID value.

And that’s all there is to this pattern! Now you can quickly create external identifier fields that are consistently derived and simple to troubleshoot.

Auto-naming Records in Salesforce

Usually on Sales Cloud implementations, business users will want to know, "What should we name our opportunities in Salesforce?" Great question, and a better follow-up, "How can we get our users to follow this convention?"

The Best Practices for Sales Managers still recommends, "Opportunity name reflects what the deal entails. ... it will help to simply adopt a consistent opportunity naming convention." While there are many ways to automatically name a record in Salesforce, each having different pros and cons, the method described below should offer the greatest flexibility and ease of maintenance for administrator.

When implemented for Opportunities or for any object, business users will be able to:

• Create the record with a custom name; or
• Create the record with an automatically generated name matching the naming convention

Furthermore, business users will be able to:

• Change the record name later, regardless of how the name was generated
• Easily revert to the automatically generated name

One Rule. One Field. One Update.

All that's needed are three components: a formula field, a workflow rule and one field update.

For simplicity and consistency across objects, the formula field can be called Auto Name (AutoName__c), and its text output should be exactly what you would expect to see based on your naming convention. What's nice about using this formula field is that you can visually see what the result would be if you were to apply auto-naming to existing records.

Next, create a workflow rule called Set Opportunity Name, with a simple formula determining the entry criteria: LEN( Name ) <= 1. The idea is that if the user types in a single character in for the record name, which is a required field, Salesforce assumes that the user wants to apply the auto name.

Finally, add a quick field update called Opportunity Name to the workflow rule. All this field update needs to do is to set the Opportunity Name field to be exactly the same as Auto Name, using a formula.

With these three components, you can help your users make the most of auto-naming in Salesforce while still giving them the flexibility of later customization.

Contact Age Formula Field

Salesforce users may want to see the current age of a contact, without resorting to mental date arithmetic based on the standard Birthdate field. Since this example is not listed (at the time of writing) in the Sample Contact Management Formulas, the formula below should do the trick for anyone looking to add this info to Salesforce.

Contact Age (Years) Formula Field In Salesforce

Due to complications in the human calendar, with leap years and different numbers of days in different months, it's not always easy to calculate the exact human age of a person for CRM purposes. In Salesforce, a more reliable method of calculating the age is through a formula field with the following formula:

( YEAR( TODAY() ) - YEAR( Birthdate ) )

+ IF(
    MONTH( TODAY() ) * 31 + DAY( TODAY() ) >= 
    MONTH( Birthdate ) * 31 + DAY( Birthdate ) , 
    0 , -1 )

The components of this seemingly complex formula are broken down below.

YEAR( TODAY() ) - YEAR( Birthdate )

This gives us the expected age. If a Johnny was born in 2000, and it's now 2013, we would expect the (max) age of Johnny to be 13 once his birthday arrives in 2013.

IF( ... , 0 , -1 )

By assuming that there is a max of 31 days in any given month, treating the month-day relationship as two "digits" in a base-31 number allows us to do a simple arithmetic comparison to see whether the birthday has come and gone in the current year. This works even for the rare February 29 birthdays.

So, if the birthday has passed, then the expected age is fine and we don't need to make any adjustments. If the birthday has not passed, then we subtract one from the max expected age to arrive at the correct current age.