The New Way to Socialize at Dreamforce 2014

This is a GREAT post by Mark Ross on greeting new and existing colleages at Dreamforce 2014! See you all next week!

The Swamps of Salesforce-Dagobah

Influenza. Enterovirus. Ebola.

Ok, come back, it’s alright. Just reading the names won’t make you sick, alright?

It’s no secret that 2014 has been a bit of a banner year for infectious disease. And, not to scare anybody, but a LOT of us are about to all gather in a location with 150,000 other people from around the world, all at the same time. I don’t know about you, but that gives me just a liiiiittle pause.

But there is a solution! And it is a good one. Recently, the Harvard Medical School published its findings on the nature of hand-to-hand communications, and the likelihood of transmission of diseases in its different forms. The short version: fist bumps are a safer and cleaner alternative to handshakes.

That’s right, you read correctly. Harvard has officially stated that we should all be fist bumping.


Absurd as it sounds, there is a very…

View original post 306 more words

Why go to Dreamforce 2014?

dreamforce_logoI hear this question A LOT from people – “should I go to Dreamforce?”

Of course, my initial reaction is “uhhhh…yes!”, but there are some great reasons why I *do* go and why I *don’t* go.  The reasoning for each person is absolutely different, but having some context to aid your decision is definitely a good thing.  *smile*

 Why DO I go?

#1  Networking and Camaraderie

Working with the Minnesota Developer Group, there are ~300 individuals that I can regularly network with for new ideas, approaches, and technologies, but we all have something in common:  we’re all here and in a lot of the same circles.  Being able to just strike up a conversation with a random person who happens to be hovering near a vendor booth you are eyeing has yielded some of the most worthwhile and contextually awesome conversations that I have ever had about Salesforce.

#2  Collaborative Learning

Apart from attending sessions, I had also volunteered recently at the MVP “Ask the Experts” booth.  I very much enjoy helping others with questions, but at the same time very seldom do you help someone and NOT walk away learning something – technology, approaches, or use cases.

#3  Bluntly:  Drinking the KoolAid!

As silly as it sounds, everyone needs some topping off.  Upcoming products and features are excellent, but just the raw energy radiating from Moscone gets your brain engaged.  For the most part, you are unplugged from “the day job” and can focus on expanding your toolset and honing your skills instead trying to balance that while racing to the next client issue.

Why DON’T I go?

#1  The parties

Yeah, there is a lot of nightlife and I always end up walking away with some hilarious story about “remember at Dreamforce when we…”, but me personally…I can’t stay out all night and still be sharp enough to enjoy the next day.  It’s only a few days!

#2  “Seeing the sights”

If you try to catch a trip to Alcatraz or some other destination during the week – while awesome as it sounds, you will fail and regret both experiences.  Save the sightseeing for the following weekend or just another time.

#3  To escape reality or wander aimlessly (not have a plan!)

Despite all of the glitz and glamour, I go to Dreamforce to learn and discover.  My career and clients depend on my knowledge and ability to bring new and different solutions to common problems – if you don’t walk out each day learning something, you have wasted your time.

If you’re going – shoot me a tweet (@andyboettcher) and let me know, maybe I’ll see you at an interesting vendor booth….*smile*

Who’s ready for Summer ’14?

Summer14T’was 72 hours before Summer ’14,when all through the ‘form

Not a developer was silent, not even the new guy Norm;

The features were dangled from the 321 pages of release notes with care,

In hopes that Uncle Mark soon would be there.

Ok, enough of that.  =)

Who’s ready for the release?  The last few releases have been absolutely chock-full of new features and Salesforce is showing no signs of slowing down, which is both exciting and really scary at the same time!

I could fill pages upon pages about the cool things coming out in Summer ’14, but here are just a few of my highlights:

  1. Description field added to Network IP Addresses
  2. Publisher Actions now available in Outlook Side Panel
  3. External Id limits raised – from three (3) to seven (7) per object
  4. Workflow/Assignment/Auto-Response/Escalation limits raised – from 300 to 500 per object (EE), and 1000-2000 per organization
  5. Trigger-ready Flows!
  6. Sandbox license types are automatically synchronized on add/remove
  7. Salesforce File Sync is GA
  8. Remote objects!
  9. Change Set deployment can now be tracked on the Deployment Status page
  10. Ability to create Price Book Entries in Unit Tests (and query for the standard price book!

What are some of your favorites?  Sound off in the comments below!

See you on the other side of the release!

Rolling back a Sandbox Refresh

Who hasn’t this happened to…you’re working a project and either someone at the company, another employee, or another consultant refreshes the sandbox without letting anyone know and unless you’re using Eclipse or Mavenmate, your work is gone.

This happened to a colleague of mine yesterday and my first reaction was, “oh that is horrible, sounds like you’re screwed.”  How wrong I was!

I didn’t believe it either when someone told me, but having worked through the process with Salesforce support with my colleague yesterday – I can testify to this being accurate and true!


Yup!  Salesforce can roll back an activated sandbox refresh if you meet the following criteria:

  • There is a clear business case as to why this needs to happen
  • You are within 72 hours of the new sandbox activation
  • You log a Case with support outlining your Prod and Sandbox org Ids
  • You are very nice to the support rep and answer their calls *laugh*
  • You have a better chance at getting this done in the necessary time frame if you have premier support, but the whole process took only a few hours

Now, I wouldn’t advise this as a normal addition to your disaster recovery plan, nor would I invoke this unless an absolute emergency, but it’s nice to know that if you were silly and didn’t have any kind of backup plan while developing (*giggle*) that you have a worst-case scenario option.

Code on!

Why you should use System.Assert

assert-sign-photoshoppedOne of the many things I do to help further the awesomeness of Salesforce and to bring more developers on board is to review code – recommending best practices, coding styles, and just overall teaching good tips to write better code.

One of the many things that I end up talking about is why verification of your unit tests is important, not just raw line coverage. Writing APEX Unit Tests is a new concept for most developers coming in from other languages and platforms.  I know it was a new concept and honestly a bit of a struggle for me coming from .NET!

Let’s start by talking about one of the most common ways Salesforce developers get bit by the Unit Test ghost.  It’s not the initial development that gets you – it’s when you have to deploy new code six months down the road after your original code has been in the wild.  Taking an extra 10-15 minutes up front to systematically verify your test results will save you hours down the road, trust me. With very rare exception, there isn’t a single Salesforce org that remains completely static and rigid for a month, much less six months. Businesses are dynamic with new workflows, validation rules, APEX code, fields, (must I go on?) being added as processes are changed or refined.

As Murphy’s Law would have it, the first organizational change done will break your unit tests, and naturally you’ll only see it when you’re pushing code at 11pm on Friday night.

Bottom line:  The sooner we accept that the world is dynamic and our code will break, the sooner we can learn how to make our code intelligent enough to help us figure out why and how to fix it.

Salesforce has a great article on “Testing Examples” – I’m not going to rehash the nitty-gritty details in this blog, but I strongly urge you to go read it. The big three things that this article points out are:

  1. Test for your desired result (POSITIVE)
  2. Test for common errors (NEGATIVE)
  3. Test as the user(s) and profile(s) that will use this functionality

Why should you always cover these three areas in your unit tests?  Two words…”Business Rules”.  What you created wouldn’t need to exist if there weren’t business rules that drove the data to it.

Who does it, what are they doing, when do they do it, where do they do it, and why do they do it?

To build a true unit test, you need to answer these questions both positively and negatively, as well as within the context of the specific user(s) that are doing it. Now you’re saying, “Ok, I get it…how do I do it?” right? Enter System.Assert, System.AssertEquals, and System.AssertNotEquals!

The first mistake I made was only to test for positive results.  “It should work here, and my Assert will just tell me if it doesn’t, that’s cool right?”  Not completely – we want to make sure we test for both positive AND NEGATIVE outcomes, as your users will never follow the “happy path” you’ve coded consistently.

Ok, so here’s your rule of thumb.  If you are changing data through variable assignment, DML, or even just through normal code logic, you need to ensure that after everything is said and done what you EXPECT should have happened…DID.

Here are some examples – keep in mind these are VERY simplistic and meant only as demonstration aids.  Please refer to the Salesforce link above for full best practices!  (try/catch blocks, multiple assertions, full logic testing, etc., are all part of good Unit Tests!)

Example Positive:

Use Case – simple insertion of Account record

Account acctTest = new Account(Name='Test Account');
insert acctTest;
System.Assert(acctTest.Id != null, 'The Test Account did not insert properly, please check validation rules and other mechanisms');

Example Negative:

Use Case – existing Validation Rule that does not allow ‘Test’ in an Account Name

Account acctTest = new Account(Name='Test Account');
try {
insert acctTest;
} catch (Exception ex) {
System.Assert(ex.getMessage().contains('Insert Failed'), 'Account Validation Rule did not fire');

Example User Context:

Use Case – The ‘Service’ Profile need to be able to execute a DML “Update” of an Account record

Profile prfStandard = [select id from profile where name='Service']; 
 User uServiceUser = new User(alias = 'standt', email='standarduser@testyourorg.local', 
 emailencodingkey='UTF-8', lastname='Testing', languagelocalekey='en_US', 
 localesidkey='en_US', profileid = prfStandard.Id, timezonesidkey='America/Los_Angeles', username='standarduser@testyourorg.local');
Account acctTest = new Account(Name='Test Account');
insert acctTest;
System.runAs(uServiceUser) {

acctTest.Name = 'Test Account - Service Mod';
update acctTest;
System.Assert(acctTest.Name = 'Test Account - Service Mod','The Service Profile was not able to update an Account properly!');


At first, you’ll be really annoyed that “I have to do WHAT?!? C’mon, the logic is right there!”, and for your initial deployment that will be the case. Believe me six months down the road when new business logic has been introduced and you are deploying new code only to see your old code is failing…

You’ll be happy that you have Assertions in there to help guide you home quickly.  =)

Questions?  Comment away!