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.
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.
What does the quickstart provide?
The Live Agent quickstart I wrote provides a super fast way to deploy a Live Agent button to Heroku. Once you have set up Live Agent, you can copy and paste parts of the configuration into the first screen of the Heroku app setup and then click deploy. After a couple of minutes you have a website that anyone can goto and interact with your chat button!
Similar to the entitlement process hands on training, I’ll be publishing it to github for everyone to use (and fork if desired). It’s going to take some time since it’s a lot of brand new content but I’m hoping to have it done before the end of the year. So, follow here and at the github repo to keep informed of it’s progress.
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!
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).
What Not to Bring
- Entertainment devices – This is a pretty big category so lemme break it down. Over the years I’ve brought things like card / board games, gameboy, PSP, extra movies, etc. All with the intention of using them in my “downtime,” and let me tell you, there is no downtime. Now if you have a long flight, by all means bring stuff with you to keep you entertained. But don’t bring it thinking you’ll find time to use it. There is so much to do at Dreamforce that you’ll barely have time to sleep. You’d be better off spending that time catching up on your sleep or meeting new people (or catching up with old friends).
- Work – Now hear me out. I know there are lots of solo admins, senior team members, CEO, CTO, etc coming to Dreamforce and it’s tough to leave work at work. Try. You’ll be better off if you focus on the talks being given, the hands on training or the networking than half paying attention while trying to do work. If you have to do work, try to set expectations that you’ll do it in the morning or the evening before the conference kicks off.
- Computers – Well, this one is a bit of a “clickbaity” bullet point. When you’re in attending a talk, shut the computer. Bring some paper if you want to take notes but for the most part, just pay attention. The slides will be provided after the talk so there’s no need to copy down every word that’s been said. You’ll absorb more of the talk if you’re giving it your full attention. Now there are plenty of places you’ll want to have your computer, such as the mini-hacks, so bring it. Just don’t use it all the time.
- All your camera gear – This one pains me to say more than any. I’m a photographer and love to use my camera. But unless I’m have planning to go somewhere like a tour or on a photo walk I found that I just carrying around a bunch of heavy lenses. If you want to bring your real camera, go minimal. This year I’ll just be bringing my D90 and my 50mm lens. Not only will it lighten up my bag, but it will force me to be creative with my work since I can’t just changes lenses.
- Your conference badge – Yes, you do need to bring it with you when you’re trying to enter any of the conference buildings. But you don’t need to be wearing it when you’re out to dinner with your team. And you don’t need to be wearing it when you’re walking around at Union Square. San Francisco is a pretty safe city, but it’s a big city. And like any big city your ultimate goal should be to not make yourself an obvious target. For some interesting reading look at things on the gray man theory*
- Preconceptions – Every Dreamforce is different and every person experiences it differently. So, take everything in the article (and every other article you’ve read) with a grain of salt. Do your Dreamforce your way and don’t succumb to peer pressure. Oh, and check your biases at the door too.
What to Bring
Yeah, I know, this is suppose to be what not to bring. But there are a couple of things that I have to list that I have found get left off of most lists.
- A jacket – I live in a state that is in a constant state of being so humid it should rain but not actually raining. A state where simply the act of walking from your front door to your car can end up with you being drenched in sweat. San Francisco is not in my state. It can get pretty chilly during Dreamforce at night, especially down near the water. Do like your mother told you and bring a light jacket. If you forget, there are typically lots of ways to win a hoodie at Dreamforce.
- An envelope – One of the first things I do when I check into my hotel room is to ask the front desk for a couple of envelopes. I use these throughout the conference to store receipts in and to store business cards. This keeps all of my paperwork organized so when I get home I don’t have to check through 30 different pockets to find a receipt for my expense report.
- An extra bag – Most likely, you’re going to end up with a bunch of extra swag (which is not an acronym for Stuff We All Get). In previous years, I’ve relied on the conference bag to be big enough to hold anything extra. Last year all of my bags were bursting at the seams so I decided to pick up a collapsible duffel bag. I’ll fly out with just carry-on bags, fill up the duffel bag and then check a bag on my way back. Check out David’s great article on how to get swag at Dreamforce.
* Just a quick note. Most of the stuff on gray man theory comes from “survivalist” or “tactical” sites. The concepts behind these are useful but some of it can be a little too tin-foil hat for me. I’d also recommend the first chapter of the Handbook of Practical Spying.
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!). Continue reading
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.
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.