Like many companies, we have a deployment process in place to handle changes in seasonal releases in Salesforce so that when a sandbox is ahead of production, we can still deploy to both without having to wait for production to be updated. Then, after both the release hits production, we go through a manual process of updating the API (primarily the ant-salesforce.jar) and the metadata to the most recent API version. Typically this just involves updating the jar and updating the API version in the request, pulling down the updated metadata and writing it to SCM. However, with the Winter ‘17 release we saw a problem trying to deploy our GlobalPicklist files after updating the API.

There are lots of times where working with Salesforce would be so much easier if it weren’t for the users. But, they’re the reason I still have a job, so you’ve got to put up with them. One of the problems with users is they tend to like to live all over the world and they all have their own ways of working and cultural eccentricities. One of the ones that has caused us grief in the past (both in Apex and in reports) is the fact that Japanese users in Salesforce default to “Lastname Firstname” when using the Name field on Users. Now, this in and of itself is not really a problem because lots of reports are written for a single user or for a relatively small group of users (such as others in the same geographical location). Where this becomes a problem is when locales get mixed with reports and all hell breaks loose.

This will be the first time I’ve written a post like this, so if it’s terrible, I’m sorry. This post will be not related to Salesforce work at all so don’t feel obligated to read it if you’re expecting Salesforce stuff.

2016 marks the 3rd year that I’ve participated in the Tuna 200 and the 5th time I’ve done a endurance relay race. I thought I’d take a moment to record how this year’s race went, what worked well and what I would change for next year

In an effort to try to reduce the amount of code in our base repository we’ve been looking at writing managed packages that we install in our production org and then delegate the development and maintenance of these packages off to other teams. Being a Open Source company we also want to try to offer what work we’ve done to other people. However, not everything we want this package to do is useful outside of our business. To solve this, we’re releasing the base package and then creating a private child package to hold most of our business logic and custom fields.

So it’s been a week since the end of Dreamforce 2016 and I’ve had some time to soak in what was talked about. This year my task for Dreamforce was to go and get some pretty specific answers. So, instead of talking about everything that happened at Dreamforce and what I think about it, I’m going to talk about the three things I was tasked with looking into.

With the recent updates to the licensing model at Salesforce, lots of companies now get Live Agent licenses included. Because of this I’m working on a hands-on training for how to setup Live Agent and use it in Service Console. As you could guess, this isn’t an quick thing to do so I’m splitting it up into parts.

Quickstart

Why?

One of the hardest parts of Live Agent to test out for non-developers is the actual web front end part. If write the HTML locally and then you can test it but others can’t. To make it so others can test it, you either have to set up a web server or figure out how to deploy it to a cloud provider such as Heroku or Openshift. And that can be pretty daunting for someone that’s just trying to setup a proof of concept or is just working on the configuration side and will pass it off to someone else from their web team.

By this point, you’ve no doubt read plenty of articles about what to bring to Dreamforce and how to prepare. If you’ve not had the chance yet, do yourself a favor and checkout the Dreamforce Trailhead module. But that’s not what I’m here to talk about. I want to talk about things you shouldn’t bring to Dreamforce, specifically things that I have brought in the past. So, let’s learn from my mistakes!

Dreamforce Ready

If this upcoming Dreamforce is your first, buckle up! it’s a wild ride. 2016 will be my 5th Dreamforce and I’ve brought a bunch of things over the years thinking I would need them and ended up not using them at all (or barely).

There are many stories like this, but this one is mine. I was born in North Carolina… wait, that’s probably too far back.

Becoming a Code Monkey

Since an early age, I’ve known that I’ve wanted to be a programmer. I use to “design” web pages on Angelfire and dabble in BASIC back in middle school. Looking back now, it wasn’t anything special but it was the catalyst that would carry me into some of my high school classes and eventually on to my degree in computer science from North Carolina State University (go Wolfpack!).

As part of my managed package crusade I decided I should delve into the world of Visualforce from a managed package. While pure Visualforce is going to be in my package that’s not nearly as interesting as packaging and using namespaced components as part of the package. So let’s take a look at how we can use a namespaced component.

Namespaced Component

The component that I created in my packaging org is simple. The Visualforce page provides an account Id and the component lists out each of the account’s cases. This component isn’t going to win any awards for originality, but it will serve it’s purpose.

Recently I’ve been working more with managed packages and I knew that I’d be writing REST interfaces inside that package. However I had no clue how namespaced REST interfaces would be presented or how you accessed them. I was afraid that there could be conflicts. For example if the package exposed /lastcase and the customer’s org had /lastcase how would they play together. I’m very happy to announce that the folks at Salesfore are on the ball and the platform handles it wonderfully.