9904 — Is it an Illuminati Symbol? Or Just Good Fun?


Do you know this woman? She seems innocent enough, but stick with me my friends as I take you down the rabbit hole, behind the looking glass, make you swallow the red pill (or was it blue, I never remember). I’m about to blow your mind!

Today was Chris Duarte day and I can’t think of a more deserving person to have their very own day. However — something is amiss. Something is not quite what we thought it was. You may know Amber Boaz, or “Amber9904” as she likes to call herself but I’m on to her shenanigans — yes shenanigans! Suspicious, what is this “9904” that shrouded in such mystery? (To be honest I *still* don’t know that answer), BUT as you’ll soon see, today she pulled off a caper right underneath our very noses! She had to have had help from the illuminati…but that’s for a different day.

Let’s examine her twitter timeline from today shall we?





Not that I need to continue — we know where this is heading!! But here we go nonetheless.


What treachery? What debauchery is this? Did we actually just get Rick Rolled? Not once, but TWICE? Well Played Miss 9904, Well played, but we’re watching you now…we’re watching you.

P.S. I reached out to Miss 9904 for her thoughts on this scheme to which she replied: “No Comment!”

P.P.S. And I still have no idea what 9904 means…but I’m still thinking illuminati.


Anyone Can Code

Last week I had the opportunity to help someone who was learning to code through one of the many different programs available to us, the Salesforce community. Whether you’re learning from the RAD Women program, Trailhead, one of the Salesforce provided classes, or simply teaching yourself, you will find at times that you hit a wall where things start to not make sense. Or maybe you start to fall a bit behind when the concepts start getting heavier.

One of the resounding things I hear from people that I’ve helped in this situation is actually rather alarming. What I’m hearing are people saying they feel dumb, or slow, or feeling like an idiot. Please, for the love of all that is good STOP thinking this way. What you are doing is hard, and its new and likely something you’ve never done before. Think of it like learning a new language or learning to play the piano. You wouldn’t sit down after a few short weeks and expect to crank out the Bach, Mozart, Beethoven symphonies would you? It’s all very much the same idea: practice, practice, practice.

I posted a quick Periscope about this over the weekend but seeing as how those things disappear after 24 hours, I thought perhaps instead of posting about my usual stuff, (don’t worry more lightning coming soon), that I’d just post these words of encouragement for those that may need it.

Just keep doing what you’re doing and remember: I’m always here to help.


Everyone’s an Admin

Okay, so I had part two of my lightning components exploration all planned out but — I haven’t executed it yet, life just sorta got in the way. To that end, awhile back I recorded a new song: “Everyone’s An Admin” and had sent the rough draft to a few people and even performed it at #SoutheastDreamin. My plan was to do something more “official” but given that life sorta gets in the way sometimes, I don’t see a chance to do this one “right” for a little while yet, so here it is in its rough draft form, “Everyone’s An Admin”:

Hopefully I’ll have some time to get the next part of my lightning topic ready to fly by next week. Until then, I hope you enjoy the video.


Trailhead on the Road

Today is the Salesforce World Tour Chicago event. Sadly, I’m here…writing this…whilst many of my colleagues are in Chicago, but I digress. I’m here for a purpose (besides billable hours). At this event, there is a flyer being circulated talking about this wonderful thing called “Trailhead on the Road” and while I didn’t create this thing, there are numerous questions being asked and the person who can answer those questions is nowhere near a laptop at the moment and is enjoying a sunny spring break in Florida. Therefore, hopefully you’ll allow me to fill that gap momentarily.

Like many great ideas…it was born whilst sitting in the airport coming down from another week at Dreamforce. For the background, you can read this, go ahead, I’ll wait…

All caught up? Good. As we were wrapping up that event, someone mentioned that we need to take this “on the road” which started another run of excitement. What would that look like? Where would we go? Could we even pull it off? The answer to those questions are: Pretty freakin’ awesome, wherever we can, dear God I hope so. :)

We are attempting to pull off our first “On the Road” event in Chicago on May 7th, 2016. The final content is still being produced but it will be lightning heavy on both the admin and dev sides. We will have several Salesforce.com MVPs in attendance, and will have two tracks. Each track may even go “off road” just a bit to assist in getting a bigger picture and a more “real world” example.

The event is not sponsored by any entity in particular so no sales pitches, just like minded devs and admins getting together to crack a few modules, and do some off-roading with Trailhead (and beyond).

If you’ll recall, I believe back in July of 2015 there was a “Trailhead Live” promotion all over the country. Its quite a bit like that but is being put on by members of the community.

Who knows where it will take us, but feel free to reach out to myself (in the comments and on twitter), or @JennyJBennett or the mastermind behind the whole deal: @chattyadmn for more information.

Until next time…


Thinking About Lightning Application Architecture: Part 1

One of the things that really surprised me when I started poking at custom Lightning Components/Apps was the fact that I truly had to handle navigation from scratch. As a developer, we’re taught to never re-invent the wheel and to write code that is re-usable up front. Over the next few posts, I hope to discuss what I’ve found, what I’ve tried and what I’ve ultimately come up with when facing these challenges.

When I started out, I knew that navigation was something that I didn’t want to have to solve every time I set out to write an application. I knew I’d need a core group of components and events that would work in concert with one another and I knew that I’d have to keep these components generic enough that they could be included in any apps that I wrote. What I’ve come up with thus far appears to be working and I’ve done a demo for a couple different people and haven’t had any major “gotchas” pointed out to me yet. I’m still trying to get the ear of some other folks that I know are much more into Lightning than I am just to level set my expectations and find out if I’m really off in the weeds or not.

Before I get into the nitty-gritty, the back story here is that I had a customer approach me about creating a Visualforce page for a very complex custom object in their org. They wanted to be able to use the page in both the browser and on Salesforce1. If this were a simple object, this could have been simpler I imagine, however there are numerous dependent picklists that forced the original VF page to be spread out amongst several other clicks/refreshes, etc. This was not going to translate well to Salesforce1. Also, we wanted to avoid two different processes, one for mobile and one for the web. I made a couple of suggestions and one of them was to create a custom app that could be “created” via App Builder for use with Salesforce1 and an app that could be accessed via the web interface. (I’ve since done some playing with lightning out and prefer going that route for the web interface as it feels more native to the Salesforce experience).

However, budgeting for such an endeavor was a challenge because I’d never done anything like this before. I’ve been through the trailhead modules, taken a HOT at Dreamforce and toyed with it a bit on my own but only using rather simple examples. This was a chance to step back and tackle a “real world” scenario. I dove in far enough to realize, as some of my past blog posts have eluded to, that Lightning really is a “framework” in the most true sense of the word. There are just enough features there for you to work with, but you are left to your own devices to get things off the ground. Therefore, I started an example project in a dev org and this is what I’ll be going over in the coming posts.

Since #TahoeDreamin had just ended, and Apex & The Limits had been asked to travel to #SEDreamin — conferences were stuck on my mind. So my sample application was a very basic conference management application, its not fully baked and I plan to write more, but currently its just venue’s and conferences because…well consulting and billable hours take precedence. (Hey kids gotta eat man!)

The actual components are simple enough that I could use pre-built items for display, etc but I wanted to see how the system would behave with completely custom pages/forms, etc. since my clients’ application was not going to be able to take advantage of things like default page layout, record pages and what have you.

Rather than discuss the ins and outs of creating my custom objects, I’ll just tell you what I have and leave you to your devices to create them (or something similar) if you’d like to follow along. We have a Conference object and a Venue object. Each object has its own information, like addresses, start dates, end dates etc. Again since that’s not at all what this post is about, I don’t want to spend too much time here. Let’s get to thinking about the structure of the application since we are trying to be generic anyway.

I wanted to be able to navigate to a list of conferences or a list of venues so I knew I would need a basic component to display these links to me. I knew I would need custom components to display these lists and informational pages. What I didn’t know was how to navigate between the two. My intuition told me that selecting a record would need to fire some sort of event that I could handle and initialize/load the appropriate component. I had been googling and not found a standard, built-in navigation method. I did find e.force:navigateToSObject and other similar events, but those only work in Salesforce1 (according to the docs) & I needed this to work in the web interface as well. On top of that, I needed a component to fire that event anyway. I knew I needed to fire a custom event and it was looking like I would also need a component to fire it.

However, that’s only part of the problem. Even if I managed to fire this custom event, how were people swapping components in and out. And then I came across this. Basically, I needed to create a container component that would house my custom components and swap them in and out of there.

The last piece I needed was some generic code to be able to handle my custom event, get the name of the component I intend to load and have my container component’s controller load that component. I created a “Base Component” that will be my container and a matching controller that will initialize my entire app (based on a parameter, but more on that later) and also handle my “navigation” by swapping out custom components as signified by my custom event. That looks something like this (I’m using the Lightning Design System to style things):

<aura:component implements="force:appHostable,flexipage:availableForAllPageTypes" controller="BaseComponentController">
	<aura:attribute name="appName" type="String" />
	<aura:attribute name="activeComponent" type="String" />

	<aura:handler name="init" value="{!this}" action="{!c.doInit}"/>
	<aura:handler event="c:NavigateToComponent" action="{!c.loadComponent}" />

	<div class="slds" style="padding: 10px;">


And my Base Component’s controller (NOTE: much of this code should be moved to the helper class, I just haven’t gotten there yet):

    doInit : function(component, event, helper) {
            //ignore this bit for now, more on that later
            var action = component.get("c.getDefaultComponent");
            	"appName" : component.get("v.appName")

            action.setCallback(this, function(response) {
            	var state = response.getState();
            	if(state === "SUCCESS") {
            		//load new component
            		var defaultCmp = response.getReturnValue();
            			function(newComponent) {
            				component.set("v.body", newComponent);


    //this is the custom swapping of components piece...
    loadComponent : function(component, event, helper) {
        var newCmp = event.getParam("targetCmp");
        var attrs = event.getParam("attributeList");

			function(newComponent) {
				component.set("v.body", newComponent);

The “magic” here lies in my controller’s loadComponent function. You will notice that my Base Component is handling a custom event called “navigateToComponent” — this event gets fired by another custom component (we’ll discuss that in my follow up post), my base component will handle that event and inspect it for the name of the component I’d like to load as well as any custom attributes my new component will need, such as the ID of an object I’m trying to load into that component. This function calls $A.createComponent which loads an instance of my component, and swap it into place where my Base Component has {!v.body} specified.

So now “theoretically” (this is all just my observations, but it is indeed working) I can fire my custom event, pass in the name of any component and its attributes and load it without my Base Component having to know anything about the component it is loading nor its data. If I use this base component in all my future apps (along with my custom event), navigation is solved for me.

That’s plenty of writing for me, and reading for you at the moment I think. Hopefully next week, I’ll have the custom event queued up for you :)


New Trailhead Trail to Help Answer That Question: “What is it that you do exactly?”

If you work in I.T. or anything remotely to do with “technology to solve business needs” then you’ve no doubt been asked by your mother, grandmother, grandfather, uncles, aunts, cousins, friends, and random people at various social events “What is it that you do.” Explaining what you do to a non-technical person can get very complicated, very quickly. You can literally watch the glaze begin to form over people’s eyes as they realize that they don’t understand a word you are saying. Now, to quote Chris Duarte, “There’s a badge for that!”

Recently Trailhead release a new trail called “Navigating the Salesforce Advantage.” It seems to do what nobody has really been able to do very well and that is explain what the cloud is and how businesses benefit from it. What Salesforce is and how it leverages cloud technology, and it does so with the same fun attitude that Trailhead has become known for. (I mean one of the answers in the quiz sections reads: “Its complicated and makes you look smart” — ya gotta love this stuff.

Its been suggested that when asked the question, many people default to “I work with computers” — that’s enough for those that would just glaze over anyway. But for those that lean in just a little more, it might not be a bad idea to send them over to Trailhead for a much better answer than “I do computers.” :)

It starts out talking very basically about Salesforce the company and its four core differences: Customer Success, Innovation, Leadership, Giving Back (my favorite).

Now, for those that didn’t “checkout” after your “I do computers” answer, a group of them will have checked out after above two modules feeling satisfied that they have a better understanding of what you do with your 8 to 5 time. However that won’t satisfy the more tech savvy and from there they will move on to the module that discusses the technology basics behind Salesforce. Brief overviews of security and multi-tenancy are given. Things start getting a little heavier here and you may lose some more folks, particular when talking about metadata, there’s something about saying things like “data about data” that scares people off. (It used to drive me nuts back in the 90s — yes, I’m old). However this module clears things up a bit and then goes on to talk about why the metadata architecture is a huge advantages for customers using the platform.

Finally, if they’re still here — they’re interested in finding out more and the trail closes with my favorite topic of all time: The Community. It’s no secret that I’ve raved and raved about this community. The plethora of talented and engaged individuals means that you’re not alone, ever and help is always right around the corner.

So there you have it — there may not be any hope for those that completely glaze over the minute that anything that sounds remotely like 1’s and 0’s starts to come out of your mouth, but for those with some interest, and perhaps some drive to learn more, and do more — there’s a self-serve answer for them out there. So next time someone asks you what you do, give them a sly smile and say: “There’s a badge for that!” and point them to Trailhead.


Top Five Things I’ve Learned So Far About Lightning Components

If you are reading this, Force.com Lightning Components are something you’ve probably heard about by now. However, if your situation is at all like mine, you’re probably finding very few people doing much of anything with them yet, especially when it comes to doing so for commercial customers. Sure, you may know some folks who are messing with them in a dev org or perhaps have even written something for the App Exchange, but you’ve not really seen anyone working on Lightning Apps for their customers “in the wild.”

I think this is largely because there is quite a bit to learn, and they’re still relatively new, so for those forging ahead, you’re quite possibly in some uncharted waters. This is the boat that I happened to find myself in the past couple of weeks.

I was asked about the feasibility of doing a Lightning App for a client and while I was extremely excited, I was also extremely intimidated. I don’t yet know all the things that I don’t know, and I know that I don’t know quite a bit. (That was probably more fun for me to type that it was for you to read).

I had to do some research so I took some personal time and borrowed this client’s use case as my test bed. Don’t get me wrong, Trailhead is a great way to get started but there’s nothing quite like learning from a real-world example.

I had grandiose plans to have some workable code examples to blog about, but billable hours call and I’ve not put anything together yet that I believe one would find useful, but I did manage to learn a few lessons in the few short hours that I put in. Here are my top 5 takeaways so far:

#1) You have to create more components than you think. There’s been quite a bit of talk around reusable components, built in “stuff” etc. All of that is indeed coming I’m sure but as it stands right now there aren’t too many ready-to-fly components. For instance: I expected to find a prebuilt ui component that I could load in a list view that would be “tappable/clickable” etc. There may be one, but I couldn’t find it and after talking with a few people who are currently toying with these things, the general consensus was that I’d have to write my own. The goal of this component was to, at the very least, fire an event that I could listen to and then use that even to load a custom view component. (A force:recordView action exists, but that wasn’t going to work for this case, and even so the component that one would wire up to fire that event doesn’t seem to exist). Which brings me to the next item.

#2) Its all about Events. Components need to fire events to tell other components and bits of code you write to load/execute. I already knew this was the case but didn’t realize the extent to which you would employ events. I attempted to use an existing lightning event when my custom item list component was tapped. For some reason that event never loaded, so I decided it’d be a good time to attempt to write my own event as an experiment. That one indeed fired without issue. Then I realized that its all well and good that I fired the event (and handled it in the parent component), but then realized I’d need to fire yet another event to tell my components to swap in and out. Essentially a navigation event. (I’m still working on this but I haven’t finished…because consulting).

#3) “Physical” structure is very important to consider right out of the gate.Often times I trudge forward and just figure things out along the way, and that’s what I was doing here. However when it came time start figuring out how to swap components in an out, etc I realized that I actually need a top-level component that would own all other components. I had thought I originally created a top level component but then realized what I actually created was just the first component that the user will see. I wound up building another top level component that would house this original component as well as be responsible for swapping in/out other components as fired events dictate. I’m envisioning now that this top level component will essentially be responsible for handling APPLICATION level events (such as navigation events perhaps) and knowing which component is currently being viewed, etc. Had I thought of that fact up front, I would have saved myself some refactoring. (NOTE: this is all still theory as I haven’t completed my navigation components yet, maybe this won’t work…I dunno yet).

#4) Be as generic as possible. The overall goal — since we’re doing all this low-level component work — is to wind up with reusable components that you could possibly use in other apps. For instance, my ClickableListItem component and ItemSelectedEvent take an object Id, type and name. I can use that component and that event to display any object as well as tell whichever component that holds it that it was clicked and give that component access to the object ID through the event. I can use this in any app I write. I’m trying to remember this moving forward especially with regards to navigation. Ideally I’d love to be able to load components dynamically and have to solve that problem only once rather than re-invent the wheel for every app.

#5) It creates a ton of files. I currently have one screen and a few events but there are nearly 50 separate files. (Granted I haven’t used all of them, but they’re there). It can get hard to keep track of everything involved with a given app since components can be reused under multiple apps, etc.

BONUS: I also didn’t realize the extent to which I’d be using the Lightning Design System. I guess I’d just assumed (rather falsely) that using the ui/aura tags also would apply some sort of default style. This is not the case as near as I can tell, so I had to include LDS in my top level component. Again, I’m not sure why I was assuming I wouldn’t have to…but I assumed nonetheless.

Anyway, some of this might be way off but its what I discovered in my few short hours of exploration. Your mileage may vary.


How To Report Problems to Your Support Circle

As a consultant, I see many orgs, have written many many lines of code, and work on numerous projects simultaneously. This is always the case and if you are working with a consultant, they’re likely juggling many projects as well and have also written so many lines of code that one project tends to bleed into another, or perhaps has been forgotten entirely. Many of us don’t have unlimited storage in our brains and usually will need some refresher time when addressing issues.

Many times, when receiving requests for support on a given project, I find myself having to go back to the client to ask for links, background information, text from error messages, etc. So here are my top five things to include in a request for support to your admin, your dev, or quite honestly *any* request to a support team (not in any order):

  1. Detailed Description of the problem: Don’t simply say “User A tried to enter an Opportunity but it didn’t work.” There could be a myriad of reasons why this would fail: validation rules, required fields, security, etc. Instead perhaps you could also include the user’s profile, the type of opportunity they were entering if it used a different record type etc. Perhaps the entering of the opportunity worked but something else failed along the way, so maybe even describe how far you got in the process before it didn’t work.
  2. Error Message Text: If you are getting an error, it always helps to include the text of that error. Even if it seems cryptic to you, to a developer, some of that “nonsense” talk speaks volumes. Good devs create specific error messages for a good reason. So that when a given situation arises, that information is meant to be shared with the support team. Many times these message would be enough information in and of themselves to help someone address the issue.
  3. A link to the problematic record/page: It always helps to provide a link to the specified record or page that is giving you trouble. This way the support personnel can attempt to see the issue exactly how you see are seeing it. Many times, half the battle is simply trying to recreate the issue. By supplying a link to the problematic record, much of that time spent trying to reproduce the issue could be mitigated.
  4. Screenshots: Sometimes a picture really is worth 1000 words. In talking with support, you could be using the same terms, and talking about the same thing, but the context is COMPLETELY different. I’m reminded of a story from my helpdesk days where a remote user called in because the key fob he was using wasn’t providing him a code that was working while attempting to login. To make a long story short, our support person found out (after two hours on the phone) that the end user never received a key fob and instead was reading the numbers directly off the documentation that was sent to him…the actual piece of paper. Its all about providing context.
  5. A summary: If you ever find yourself acting as the intermediary between support and your user base, you find yourself under a swarm of emails. Whenever providing feedback, it helps to give a summary of anything that occurred between yourself and your user base in between communications. If you simply just forward an email without any commentary, the support engineer needs to hunt through what could be numerous threads to figure out where action needs to be taken. By all means, include the entire thread as it may in fact be necessary for context, but highlighting the areas of that thread that need attention will allow the support personnel to put the focus exactly where it needs to be thereby improving the efficiency of the entire process.

In closing, share as much as possible and provide a summary of that information so that support personnel can put the focus where it needs to be rather than starting from ground zero but is still able to sift back through for an audit trail, etc. Keeping these things in mind when working with support situations should provide you with a smoother, more efficient path to a solution.


Are You Going to Tahoe?

I’m not — and I’m never going to be able to forgive myself for it, but due to some personal things going on, my family just couldn’t swing having me away that weekend. That being said, I’m asking you all to consider going. Maybe you missed Dreamforce, or maybe you are “missing” Dreamforce, maybe this event will be the one where you take home something so invaluable it changes your career for good.

Here are 5 good reasons you should attend Tahoe Dreamin:

  1. It will be a more intimate setting than Dreamforce. Not that Dreamforce isn’t a good thing, but the huge number of attendees compounded with the vast array of session options, it can be a little overwhelming. These smaller events tend to be more “digestable” and due to the size of the group in these sessions, it feels less like fluff and more like stuff
  2. Great speakers & Sessions. I mean just look at this list of Tahoe Dreamin’ Sessions so far!
  3. It’s been organized by Salesforce MVP Bill Greenhaw. With Bill behind this thing — its sure to be an incredible event. For those of you that don’t know Bill, he’s very passionate about the platform and even more so about the community and his role in that community. Definitely a man worthy of praise!
  4. Dreamforce ’16 is quite a ways off and if you are anything like me, your Salesforce year revolves around Dreamforce…its how we measure time. These in-between events can help you get over that hump!
  5. Last but not least, it’s Tahoe for cryin’ out loud. TAHOE! So what the heck are you waiting for. Go, go, for all that is good and holy…GO!

P.S. Ima be extremely jealous…