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.

fistbumpforhealth

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!

WHAT WHAT?

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!');
}

TL;DR

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!

What’s coming in the “next release”?

This is a great link to see what Salesforce Ideas are due out in the “next release” – I love parsing through this a few weeks before release. I had no idea about the new Contact Layout pilot – looks AWESOME!

https://sites.secure.force.com/success/search?type=Idea&sort=2&pageNo=1&filter=Coming+in+the+Next+Release

Transition from MSSQL to Force.com

I saw an excellent question on the #askForce Twitter feed from @corycowgill today that was “Besides standard Force.com Dev Guide, anyone know good blogs / materials to ramp up a DBA on Force.com?”

I thought, “well heck, I’m an old school Microsoft VB/.NET/MSSQL programmer and I definitely had some ramp-up when transitioning to the Force.com platform.”  I figured I’d have a stab at it – trying to explain what I ran into in hopefully simple english.  =)

Step 1:  Let’s get some common footing.  Name, rank, and serial number soldier!

Let’s tackle the basics first…tables, fields, stored procs, triggers….what are they called in Force.com?

  • Table = Standard and Custom sObject
  • Field = Standard and Custom Field
  • Relationship = Master/Detail and Lookups
  • Programmatibility (stored procs and triggers) = Workflows and APEX (classes and triggers)
  • Index = yes, but not what you’re used to…
  • View = not available in Force.com

Elaborating…

Naming Convention.

  • “Label” vs “API Name”
    • Label is what your users will see that sObject or field as in the interface
    • API Name is what you will reference that sObject or field as in APEX
  • “__c” – this is a suffix you will see appended to the “API Name” of all custom sObjects and fields you create

sObjects.

You have a collection of sObjects called “standard sObjects”.  These are objects that are pre-built into your instance and cannot be deleted.  They are primarily under control by Salesforce (fields can be added as a result of a maintenance release).  You can add your own fields (custom fields) to **MOST** standard sObjects.  The “custom sObject” is a table that you create – fields, security, relationships, etc.  Standard and custom sObjects all live in the same partition – you can access both standard and custom objects from each other.

Examples of standard sObjects = Account, Contact, Event, Task, Opportunity, Campaign, Case.

Examples of custom sObjects = MyObject__c, YourObject__c, YourMom__c.

For sObjects, depending on the Edition you are subscribed to, you can have between 5 and 2,000 custom sObjects.

Fields.  

Just as you have standard and custom sObjects, you have the same with fields.  Standard fields will have names such as “FirstName, LastName, MailingAddress”, where custom fields will have “MyField1__c, MyField2__c, etc”.  Just as with MSSQL, you have the option of defining the data type for a field (I won’t go into all of them, see this link for details).

For fields, depending on the Edition you are subscribed to, you can have between 5 and 800 custom fields per object.

Relationships.

Force.com has two kinds of table relationships:

  • Master-Detail (1:n) – allows a master object to control behaviors of a child object (security model, cascading actions, etc)
  • Lookup (1:n) – links two objects together, but has no bearing on security and the option of cascade actions

You can indeed to many-many (n:n) relationships in Force.com using either of the above relationship types above very similar to how you would use a junction table in MSSQL.

For relationships, you can define up to TWO Master-Detail and FIVE Lookup relationships per sObject.

Programmatibility.

Oh man – this is the biggest spot where I really miss the features of enterprise DBMSs like MSSQL.  There are no stored procs or triggers at the DB level, at least to how you’re used to thinking about them.  Force.com does provide nearly all of the functionality that you’d normally tap via stored procs and triggers, but you have to dive into Workflows (declarative) and APEX classes / triggers (programmatic).

Before you freak out too much – bottom line is YES, between Workflow and APEX, you’ll be able to “proc” away.

In the interest of keeping on task here, I’m not going to dive into APEX on this post – if you want more info, just leave me a comment or hit me on Twitter (@andyboettcher).

Indexes.

This is double-edged sword – I both do and don’t miss being able to index any field.  I was pretty good at optimizing my indexes, but I knew a lot of DBAs who just sucked at it.

Force.com does not do indexing as you’re used to.  There are indexes on certain fields by default, such as:

  • System Time Fields
  • Id
  • Name
  • Any relationship fields
  • Standard sObject-specific
    • Account:  Account Name, Account Owner, Account Record Type, Parent Account
    • Lead:  Company, Email, Lead Owner, Name
    • Contact:  Account Name, Contact Owner, Email, Name, Reports To

Depending on your schema’s needs, you can also contact Salesforce Support if you need indexes on other fields.  I haven’t done this personally, but everyone I have heard of that has done it has been successful (after having a valid and documented use case)

Step 2:  How do I create my schema?  Where’s my trusty Enterprise Manager / Management Studio?

The most raw and fully-functional place you can go is into Setup.

  • Standard Objects:
    • Setup / Customize / (find your object)
    • Fields are located as Setup menu options under each standard sObject
  • Custom Objects:
    • Setup / Create / Objects
    • Fields are located in the “Custom Fields” section on each custom sObject’s configuration page

If you’re feeling really spunky, Salesforce released the read/write “Schema Browser” with Summer ’12 (finally!) that is pretty darned cool.  It’s the closest you’re going to get to an ERD without going to the AppExchange too.

Step 3:  What tips and tricks should I keep in mind while building my Schema?

For the love of everything holy, remember to NORMALIZE!  The double-edged sword of Force.com is that it’s incredibly easy to create sObjects and fields.  Too easy.  Many an instance I’ve walked into with 400 fields in objects that could have been far more properly been done via normalization.  =)

Create a Naming Convention.  Force.com has many examples of how they’ve approached naming conventions (just look through their online documentation or examine their standard sObjects).  Pick one and stick with it.

Along the normalization  lines – think long term and be as generic with field names (as appropriate).  Just because you can maintain seperate “Label” and “API” sObject and field names doesn’t mean you should make a habit of it.  Very little is more frustrating than having to hunt through your schema for a field with two names.


That’s a pretty good start.

Just as with MSSQL or any other DBMS for that matter – your schema is your foundation.  If you have a bad schema, you’re going to have a less-than-optimal application.  Be calm, deliberate, and thorough.  One big thing I try to impart on everyone I talk to about this is just because Force.com is quick and easy – that is no reason to execute that way.  A great saying I heard growing up from my dad while he and I would work on projects around the house – measure twice, cut once.

Questions?  Hit me up in the comments below or on Twitter (@andyboettcher).  Thanks for reading!!