Lessons learned and technical ramblings from 15 years in the exciting field of Information Technology, and specifically Software Development. Strong emphasis on Platform as a Service and Salesforce Platform for enterprise software development.
When a company submits their application for Salesforce Security Review there is often a need to provide documentation. There is a lot of information on the process and security scans here (https://developer.salesforce.com/page/Security_Review) but this doesn't have any templates or documentation standards a submission should follow for their application.
This is a sample of a template I have used when submitting to Salesforce Security Review that I have found helpful. I have gone through Salesforce Security Review more than 10 times for large OEM managed packages with hundreds of thousands of lines of code. I have found that the more information you can give the security engineers when they review your application the more successful you will be in passing your security review. Performing this documentation as part of your SDLC also helps bake this into your engineering processes, ensuring future reviews are successful.
Want to learn more? Join my engineering organization! I'm looking for new talent to mentor in multiple engineering roles! http://www.fusionrm.com/careers
You know what’s better than being able to upload 5,000 batches a day with Bulk API? If you guessed, “being able to upload 10,000 batches a day,” you’re right! The daily batch limit has been increased to 10,000 for all orgs.
2. Create More Spanning Relationships Per Object in Formulas
Sometimes you want more! We’ve increased the number of unique relationships per object from 10 to 15. This increase is available in both Lightning Experience and Salesforce Classic.
3. Daily Org Limits for Sending Emails with the API Have Increased
Using the Salesforce API or Apex, you can now send single emails to 5,000 external email addresses per day based on Greenwich Mean Time (GMT). You can also send mass email to 5,000 external email addresses per day per org. The maximum number of external email addresses is no longer based on your Salesforce edition. You can use your remaining daily balance of external email addresses in as many mass emails as you’d like, regardless of your edition. This feature is available in both Lightning Experience and Salesforce Classic.
4. Get More Days to Schedule Your Quick Deployments
The time window to quick-deploy your validations has expanded from 4 days to 10 days. This larger time window provides you more flexibility for scheduling your quick deployment and helps minimize the impact on your org.
5. Higher Limits for Standard Picklists
Standard, multi-select picklists can be as detailed as you need them to be with a new limit of 255 characters per entry. This feature is available in both Lightning Experience and Salesforce Classic.
6. Make More API Calls and Get Fewer Headaches When Calculating API Limits
We simplified the API request limit calculation and gave everyone more calls per 24-hour period. For Enterprise Edition, Unlimited Edition, Performance Edition, and Professional Edition with API access enabled, the old calculation was based on your number of licenses and the license types, with a guaranteed minimum of 15,000 calls per 24-hour period. We scrapped the minimum and gave everyone 15,000 more calls. The calculation for Developer Edition orgs and sandboxes remains the same.
I recently passed the Salesforce Certified Integration Architecture Exam. The full exam details can be found at the SFDC Architect Academy. This is one of the 9 Architect Domain Specialist exams. In this post I'll be providing my general thoughts on the content of the exam. Here is the description of the exam from the Architect Academy:
Scenario Based Questions
The exam asks multiple scenario based questions where you need to choose the right integration pattern given a set of criteria. For example a question may look something like:
Delivery Express has a Salesforce.com Org that is holds all the customer information including Accounts and Opportunities. Delivery Express has a on-premise ERP system that is the order fulfillment system. The ERP System has a SOAP API for creating and updating orders and is offline occasionally for maintenance. Delivery Express has a new requirement whenever an Opportunity is Close-Won an order should be created in the ERP. The order needs to be near real time and custom development work is not an option.
Which technology should the Integration Architect select based on the above?
A. Outbound Messaging
B. Apex Callout
C. ETL Tool
D. Canvas App
The above question can be answered with A because Outbound Messaging can be setup custom development, can retry failed messages automatically, and supports SOAP API endpoints.
Know Your Integration Options
MashUps
You need to know when to use a mashup. If the requirement is to simply view the data in SFDC UI then you can look at doing Canvas or Custom Web Tab. Use a Canvas if you need authentication and Custom Web Tab if you need to surface an external website that is unauthenticated.
Middleware, ESB & ETL
You need to know when to use ETL and Middleware to solve your problem. Do you need complex error handling and orchestration across multiple systems? Then you're going to need to use an ESB, Middleware, or ETL tool. Do you have a data synchronization that does not need to be real time but handle large data volumes? Again an ETL tool using Bulk API is going to be your best bet.
Apex Web Services
You need to know when it makes sense to incur the technical debt to build out a Apex Web Service. Do you need to multiple DML statements on the SFDC Tier as an atomic operation? Than you need to look at using an Apex Web Service to handle the transaction as a single API call.
Apex Callouts
How do Apex Callouts work? You need to know that an Apex Callout cannot fire inside an Apex Trigger. A trigger has to invoke a @future method that in turns does the HTTP Callouts.
Bulk API
You should know when and how to use the Bulk API. How can you monitor a Bulk API job? Through the UI and through API calls? What is the difference between Serial and Parallel modes? What API's support Serial and Parallel?
Avoid Record Lock Scenarios and Performance Issues
The answer is not to always do the work on the SFDC Tier. Many times you want to pre-process your data before you load it into SFDC. One example is to group your data by a parent record like Account so that Bulk API jobs do not fail due to parent record locking. Also for example if you are integration large volumes of data you do not want to do upsert you want to do separate insert and update calls respectively, forcing you to pre-process those ID's in your data set.
Want to learn even more? Join my team!
I am currently looking for the next set of Force.com Engineers to mentor. If this type of technical content and challenge seem appealing to you, and you want to become an all star Force.com Engineer across the entire Force.com PaaS Stack, reach out to me on Twitter or Linkedin. I am looking for several USA based engineering roles to join my engineering team at Fusion Risk Management (Sorry I cannot provide visa sponsorships ).
I recently passed the Salesforce Certified Data Architecture and Management Exam. This architect exam is one of 9 new Domain Specialist exams that constitute the SFDC Architect Academy certifications. There is a study guide and more details on the exam here: http://certification.salesforce.com/architects. The number of questions, passing score, and other information can be found there. In this post I am going to talk about the general questions, experience, and content that was on the exam.
Know Large Data Volumes (LDV)
Large Data Volumes refer to Salesforce.com Environments that have millions to hundred of millions of records. The underlying multi-tenant architecture of the Force.com platform solves lots of problems and creates some interesting ones. LDV environments pose some interesting technical challenges that other orgs don't often face including but not limited to:
Several of the questions revolve around understanding data management. This includes Data Quality best practices (Using Data Duplicate Matching Rules, Validation Rules, Reports and Dashboards for Data Quality KPI) as well as Data Governance Programs and Systems of Records. There are several questions about maintaining data integrity between SFDC and 3 other systems. How do you maintain a System of Record across the Systems?
My advice is to understand the mechanisms for Data Quality on the Platform including:
Data.com
Duplicate Management Capability of Salesforce.com
Lead Conversion
Merge Accounts
There are also questions about setting up a Data Governance Program. What roles do you need for a Governance Program (Data Stewards, ETC)? This is that architecture considerations and how do you technically run a program as the data architect.
Know Data Loading Options
This is part integration and part data management. You need to know what options are available to integrate data across systems. ETL Tools, Data Loader, SFDC Data Import Wizard, Outbound Messages, SOAP and REST API considerations. For example one question asked about considerations for loading millions of records into the System on a frequent basis (You need to think about API Limits!). Another question asked about using Outbound Messaging to do a outbound read-only synchronization to a ERP system for Opportunities. You should be familiar with all the integration options with respect to data layer integrations.
Conclusion
This exam validates that an architect candidate has performed implementation of, or is familiar with large, complex Salesforce Orgs. I hope the above material will give folks insight into this new exam.
If you want to learn more connect with me on Twitter. I am looking for the next set of great Force.com Engineers to work with. If you are in Chicago especially network with me. I am looking to hire talent that I can mentor and grow our Fusion Engineering Team with!
Bubble Sort in Apex
The bubble sort algorithm is one of the first sorting algorithms that computer science students learn. It can be thought of as the "Hello World" of sorting algorithms. It is very easy to implement the code, and the algorithm itself is fairly straightforward. The trade off of is that for large data sets it has the worst performance of all the sorting algorithms.
In a bubble sort, an array of values is iterated over one element at at time. The current element is then compared to the next element in the collection. If the current element is greater than the element that is next in the collection, the two values positions are swapped in the collection. The algorithm will iterate over the collection multiple times until all the elements in the array are ordered. In each pass the highest value element is moved to its position in the array, hence the term "bubble sort". It's like the value has "bubbled" its way to the correct position in each iteration.
Now to the fun stuff. The following code will perform a bubble sort in Apex, which runs on the Salesforce.com PaaS.
Here are some logs showing it working as expected.
How useful is this in real world application of the Salesforce platform? Not very. It is much easier to use the optimized sorting algorithms on the Apex collections objects themselves (List.sort()) for example. Or if you ware working with a SOQL query simply using ORDER BY on the query will sort for you.
However it is a fun little piece of code and illustrates that you can teach core computer science principals on the Salesforce platform. Enjoy!
This is the second post where I am working with the CloudBit and Salesforce.com. In my first article I made a very simple LED light up when an Opportunity in Salesforce.com moved to a stage of "Closed Won". The second time around I decided to get a little bit more creative. And what is cooler than recreating your very own Salesforce.com Dashboards in real life with some cardboard, markers, and some littleBits!
littleBits Components
1. USB Power Module
2. CloudBit Module
3. Servo Module
Salesforce.com Components
1. Salesforce.com Report & Dashboards
2. Salesforce.com Analytics API
3. Apex Class to invoke API and littleBits Cloud API
Step 1 - Create a Salesforce.com Summary Report & Dashboard
For this example I created a Salesforce.com Summary Report. The report summarizes the total amount (value) of Opportunities that have a Stage of "Closed Won".
Once you create the report you can create the dashboard with the report as the data source. Create a gauge chart in your dashboard and set the minimum amount to 2 million and the maximum amount to 5 million. The gauge chart maps well to the Servo littleBit.
Step 2 - Map the littleBit Servo Arc to the Gauge Value Range
The littleBit Servo has two basic modes: Step and Turn. In turn mode you can move the Servo to a specific degree based on the voltage you pass to the Servo. You can set the voltage from 0 to 100. The littleBit Servo has an arc of 145 degrees. So you will lose some precision as you can only set integer voltage values.
To give a rough voltage value you can take the range of values in your gauge (5 million max - 2 million min - 3 million range) / 145 degrees = 20689 dollars per degree in the chart. The amount of voltage is 1% of voltage = 1.45 degrees (145 degrees / 100% voltage = 1.45 volts percentage per degree).
Step 3 - Call the Salesforce Analytics API to get the Gauge Value
Call the Salesforce.com Analytics API to get the values from the Opportunity Report. You can use the following Apex Class which will call the Salesforce.com API and convert the values into the appropriate voltage for the littleBit API.
public class LittleBitsReportManager
{
public static LittleBitsManager.LittleBitsOutputPayload runOpptyGaugeReport()
{
// Get the report ID
List <Report> reportList = [SELECT Id,DeveloperName FROM Report where
integer duration = -1; //Set the voltage peermamently until it is overwritten
LittleBitsManager.LittleBitsOutputPayload outputPayload = new LittleBitsManager.LittleBitsOutputPayload(outputPercent,duration);
System.debug(JSON.serialize(outputPayload));
return outputPayload;
}
}
Step 4 - Invoke the littleBits CloudBit API
Using the same Apex Class "LittleBitsManager" I created in the previous post you can call the CloudBit to set the Servo to match the Dashboard Gauge in Salesforce.com.
This simple line of code will reuse our code from the previous article and use the new code above to call the CloudBit.
Executing this line of code will make the "Real Life" Dashboard match the Dashboard in Salesforce.com. Let's see it in action!
You can take this to the next step and make this run via Scheduled Apex every 5 minutes to create a dashboard in your office! Put additional reports and charts together with more CloudBits and littleBit components to create multiple chart dashboards!
Recently I received a littleBits CloudBit starter pack as a holiday gift. For those of you who don't know what littleBits are you check them out here: http://littlebits.cc/ I like to think of them as LEGO's for IoT. I have played with Arduino and a few other maker packs but they all have a pretty steep learning curve. For example, to get my Arduino setup to talk to the cloud I had to setup a Node.JS server on my local mac, program an Arduino Sketch, and mess around with a breadboard breaking multiple transistors along the way. I have shaky hands! I like Arduino but I wanted something that was a little easier to play with. Enter littleBits.
Whereas LEGO's have interlocking blocks, littleBits have interlocking components via tiny magnets. There are several types of littleBits that you snap together to form electronic circuits (power, inputs, outputs, and wires). Below is the very simple circuit I built for this demo. It has only 3 blocks. The USB Power, the CloudBit, and a LED Light.
This makes it super simple to create IoT devices. The cloud module I have also automatically syncs to the littleBits cloud and has REST API access, as well as IFTTT connectors. I wanted more granular control over my integration so I chose to call the CloudBit API directly via REST instead of the IFTTT connectors available.
So the first thing I wanted to do was set this up to work with the Salesforce1 Platform.
3. Setup your littleBits Cloud Account via the CloudBit instructions.
Salesforce Setup
Once you have setup the your littleBit cloud account and done the first tutorial that show you how to set it up, you are ready to move on to calling your device from other cloud platforms via the littleBits Cloud HTTP API. From Salesforce.com we will be using APEX HTTP Callouts to send JSON payloads to our littleBit CloudKit device.
Step 1: Setup the Remote Site
In Salesforce.com Setup navigate to "Remote Site Settings" and create a Remote Site Setting with the remote site url of: https://api-http.littlebitscloud.cc
Once the Remote Site Setting is configured we can work on creating our Apex Class.
Step 2: Create the Apex Class "LittleBitsManager".
Using the Developer Console or the Force.com IDE, create the following simple Apex Class. You will replace XXXXX in the URL with your Device ID and xxxxxxxxxxxxxx in the Authorization Header with the Authorization Token in your littleBits cloud setup.
public class LittleBitsManager
{
//If we want to make a callout to littleBits from a Trigger, we have to do it Asynchronoushly.
@future(callout=true) //callout = true allows HTTP Callout from Apex in Async Context
public static void sendOutputReqAsync(integer percent, integer duration)
//Request Payload in Apex to hold the values we are sending to littleBits.
public class LittleBitsOutputPayload
{
//Percent is the amount of output voltage you want to send from 0 to 100% as an integer
public integer percent {get;set;}
//Duration is the time you want to set the voltage. 3000 milliseconds is the default as specified in API docs.
public integer duration_ms {get;set;}
public LittleBitsOutputPayload(integer inputPercent, integer inputDuration)
{
this.percent = inputPercent;
this.duration_ms = inputDuration;
}
}
}
Step 3 - Invoke the LittleBitsManager Apex Class from a Apex Trigger
This simple Apex Trigger will invoke the littleBits Cloud Asynchronously via the above Apex code. Our simple use case is when someone closes an opportunity in Salesforce we should light up an LED.
trigger OpportunityTrigger on Opportunity (after update)
{
//Always put this logic in a Trigger Handler never in trigger code
//For example for littleBits this will be ok
for(Opportunity oppty : trigger.new)
{
//If an Opportunity has a been moved to a stage of Closed Won let the team know! Light up the Board via littleBits
Here is a simple demonstration showing everything running together. When the Apex Trigger fires the call is made to the CloudBit to light up for 10 seconds. This is a very simple use case but shows how simple it is to get the "plumbing" working between the two platforms. With 100's of different cloudbit connectors and the flexible platform of Salesforce 1 you can literally build any type of IoT application you can think of rapidly!
Note: Reid Carlberg from the Salesforce.com Evangelist team already did a very similar setup here where he uses IFTTT and Twillio / SMS to activate a CloudBit. If you want to see how to use IFTTT and not code directly against the CloudBit API it's worth a view! (https://www.youtube.com/watch?v=Pa9QrwEhuSA)
I recently took the sample PDF Forms Service I built for Dreamforce 2014 and have made it available via GitHub and the Heroku Deploy button.
The Heroku Deploy button is pretty slick. It will automatically provision an App on Heroku for you with a click of the button!
So know you can not only look at my source code on GitHub, but you can also instantly spin up the Form Service Sample App on your own Heroku account! With just a click of a button!
Here is the Simple REST PDF Form Service Heroku Deploy Button! Go forth and build!
If you have question on how the actual Form Service works check out my session from
Dreamforce 2014 here:
Any experienced Salesforce.com developer will tell you that Apex Unit Tests are critical to the success of any Salesforce.com implementation. This is especially critical in complex Salesforce.com environments where we have multiple lines of business using the system. Imagine if you have 10 completely different business units using the same objects with different record types, workflow rules, visualforce pages, batch processes, triggers, etc.
Here are some random thoughts on how you can get the most of out your Unit Tests. These have helped me in the past.
Build is not complete without Apex Unit Tests
Unit tests should be completed as functional code is delivered. A story or task should not be considered complete until the accompanying unit tests are built. As yourself "Can I deploy this functionality to production successfully? Does it have code coverage?". SFDC will stop you without sufficient code coverage.
Apex Unit Tests without system asserts are worthless for support and maintenance
Unit tests need to have system.assert() to be of any practical value. If a unit test executes solely for the purpose of code coverage than it is not doing its true job, which is to guarantee system behavior. The developer who changes this code may think everything is fine because your unit test did not fail, but his change actually broke the runtime code.
Deployment between sandboxes must pass all unit tests
The Salesforce platform only requires unit test coverage for production deployment. If you bake this into your deployment processes you will ensure success in a large enterprise SDLC that has multiple environments.
If you have complex workflows, validation rule logic or Roll-Up Summary Fields (RUS) build some Apex Unit Tests to validate it even if there is not Apex Code.
You can use unit tests to validate your "clicks not code" functionality if it is significantly complex. For example if you have RUS fields that have complex filters and get used across several objects for logic. Putting Apex Unit tests in place can help ensure future changes to these items will not corrupt your data.
Recently I had the need to convert a base 10 number into a base 32 number in Salesforce. For my project I had a need to integrate SFDC with a legacy AS400 database to store records (contract records).
The Contract Number Requirements
The legacy database had an existing field that had a length of 9 for the contract number, with the first 4 characters a standard prefix, and each number which had to be unique.
For example the contract number looked like "POLY48GH3" where POLY was the prefix, and 48GH3 was the number. If you've ever worked with legacy AS400 databases you know they love to limit the amount of characters in a field! Furthermore we couldn't use the characters W,X,Y, or Z in the field and could only use 0-1, and A-V as uppercase only.
Fun requirements right!
The Solution
We quickly identified that if we used base 32 numbers we could get the most unique numbers out of the 5 available characters per our requirements (32^5=33554432 available numbers). In Java you can achieve easily this via the standard class/method Integer.toString(integerVal,radix) where you can specify your radix (base). There is no corresponding method in Apex!
You can use EncodingUtils in apex to do Base64 and even Base128, but if you need to tailor your base you are out of luck. To do custom base conversions you need to write your own method to accomplish this, which I have provided below. You can tweak this method to create different base conversions as necessary. Also you could probably write this in a Formula Field with some additional work if you didn't want to do it in Apex.
I hope this helps folks. A big shoutout to the computer science blog from Erik Oosteral which outlines this logic for those who are interested.
//We want to ensure all characters have a value. So if the Base 32 number is 10, and our Contract Number lenght is 5, we want to make the output String "00010"
There are many instances when you develop on Force.com where you will have to gather performance metrics on your codebase. You may want to log how long a HTTP Callout in Apex code takes, or how long an Apex Trigger runs with complex sharing rules. Gathering these metrics is especially important on the Force.com platform due to Governor Limits and the impact of having long running apex transactions. Unfortunately the native logs on SFDC do not allow you to log more than 20 transactions per user per transaction batch. Also these logs are not easily reportable.
This can present a clear challenge to developers but it can be easily remedied. In this blog post I will show you how you can roll your own Apex performance monitoring framework. You will be able to log performance on your Apex code, easily toggle the monitoring on or off without a deployment of code, and run reports and dashboards on your metric data. All this natively on the Force.com platform! No additional tools or vendor products need apply!
Step 1: Create a Custom Object For Performance Logs
Our first step will be to create a custom object to hold our performance logs. This object will have only a few fields.
Name - An Autonumber for the transaction in the format of PERF-{00000001}
Apex Class - A string holding the name of the Apex Class for the transaction
Apex Method - A string holding the name of the Apex Method for the transaction
Time in Milliseconds - A number holding the transaction time in milliseconds
Time in Seconds - A formula field based on Time in Milliseconds for showing time in seconds
Notes - Any developer notes you want to add for details about the transaction (Record Ids, etc)
Created By - The user who was executing the code
The total object looks like this. Note: Make sure to "Enable Reports" so we can write native reports!
Bonus: Create a Custom Object Tab and expose the object in your UI if you want.
Step 2: Create a Custom Setting to Toggle Logs On/Off
Now that we have our custom object we need to create a Custom Setting that will allow us to toggle the logs on or off without changing any code. Custom Settings were specifically built to set Application Wide settings like this and is the perfect use case for Custom Settings. We are going to create a Custom Setting called "Global Setting" this is Setting Type "List".
We are only going to create one custom field called "Log Transactions".
Once we are done your Custom Setting will look like this:
Step 3: Create our Apex Monitoring Framework Class
Now that we have our data model complete we can build out Apex framework class for monitoring transactions. The class itself is very simple and really only does 3 things:
1. It automatically logs the transaction time by calculating the time in milliseconds.
2. It reads the Custom Setting to see if logging is set to true.
3. It will insert a log record via DML insert on the System Performance Log.
//Class used to maintain the State of the Transaction for use by Apex Classes.
publicclass PerformanceTransaction
{
publiclong startTimeMilliseconds {get;set;}
publiclong endTimeMilliseconds {get;set;}
public String apexClassName {get;set;}
public String apexMethodName {get;set;}
public String notes {get;set;}
public PerformanceTransaction(String apexClass, String apexMethod, String innotes)
{
apexClassName = apexClass;
apexMethodName = apexMethod;
notes = innotes;
startTimeMilliseconds = DateTime.Now().getTime();
endTimeMilliseconds = 0;
}
}
}
Step 4: Instrument our Apex Classes with the Framework
Now that we have our data model and Apex framework classes we can start to instrument our Apex classes and methods. To do this we only add two lines of code to the methods we want to instrument.
The first line of our Apex methods should invoke the constructor in our framework for a transaction log like this:
SystemPerformanceDAO.PerformanceTransaction performanceLog = new SystemPerformanceDAO.PerformanceTransaction('AccountController','refreshContacts','Account Used: ' + acct.Id);
And the last line of our method should simply invoke our Apex class to log the metric like this:
This makes it very easy for us to add instrumentation to our Apex classes with minimal code. And we don't have to change the code since the framework automatically does that for us by checking the custom setting.
A complete example may something like this:
publicwithsharingclass AccountController
{
public List<ContactListWrapper> acctContacts {get;set;}
publicAccount acct {get;set;}
public AccountController(ApexPages.StandardController std)
Step 5: Instrument our Apex Classes with the Framework
Now that we have our classes instrumented we can use the native Force.com Analytics to build our reports. For this example I create a report to show the average, maximum, and minimum transaction times for each of my controller methods.
Conclusions and Caveats
As you can see in this example, it is fairly simple to roll your own instrumentation on Force.com for performance metrics. One of the caveats is that this approach will consume managed data on the platform. So you will need to monitor your logs data usage and periodically purge the records as needed if you don't have a lot of managed data.
The other caveat is that this will not work for instrumenting Visualforce Apex controller constructor methods. Visualforce Apex controller constructors do not allow you to perform DML statements.
When implementing multiple integrations with a Salesforce.com org it is a common use case to translate picklist values into system code values for legacy systems. For example, if you have a Quote object you may have a picklist called "Quote Payment Type" with valid values of "Cash", "Credit", or "Debit". These are the values that are displayed in Salesforce.com UI and the values persisted in the Quote_Payment_Type__c field on your Quote object.
However, sometimes we need to translate the picklist values into system codes for an integration. If we are integrating our Quote object with a payment system for example via a web service the legacy system may expect a system code instead of the string values displayed. In this case let's say our legacy system is a AS400 mainframe and expects short bytes for the values (Cash == C, Credit == CR, Debit == D). How should we do this?
We could do this in Apex Code and translate these values prior to making a HTTP Callout. However, that assumes that we will only integrate with this system via a HTTP Callout in Apex code. We wouldn't be translating this for Data Loader integrations, or other 3rd party tool integrations that may simply pull the SObject and pass it to the legacy system. Also if we build this translation in the Apex code layer, everytime we add a new translation or change an existing translation we would need to do a code deployment and update our unit test coverage. Ouch!
A much cleaner way to implement this is to use a Formula Field on the object.
In this case we create a new Formula Field called "Quote Type INT".
Formula Field Definition:
IF(ISPICKVAL(Contract_Type__c, 'Cash') , 'C', IF(ISPICKVAL(Contract_Type__c, 'Finance'), 'L', IF(ISPICKVAL(Contract_Type__c, 'Lease'), 'LE','NA'))) And now the translation is always done in the declaritive layer which is SFDC best practice. Here is what we get in our UI if you chose to display the system code value:
Its a simple pattern that every developer should have in their toolbox. Always remember to use "Clicks not Code" whenever possible to solve your development or integration needs. With this pattern if we add new translations I can simply update the Formula Field and Picklist values without doing a full code deployment!
One thing to consider: If you have hundreds of values you may exceed the Formula Field size. In that case you may need to use a Custom Setting or other mechanism (Static Resources, etc) to hold the translation values. But please don't hard code them!
