Posted by: Elizabeth | October 2, 2017

Disney App #1 – Brainstorming

I’ve often explained Salesforce by relating it to LEGO.  You have this big box of LEGO that within reason, you can build anything you want with.  There are certain rules you need to follow (stagger joins for strength, posts can’t connect to posts) but outside of those you are free to put together and take everything apart as much as you want.  Like LEGO, Salesforce provides new pieces and new ways to build in 3 releases a year.  These releases, these additions of functionality and streamlining, are why you want to keep as much as you can to the pieces you are given.  You have the option to make custom pieces (think 3d printer options here) using code, but they are not going to be able to take advantage of the new goodies Salesforce provides as easily as staying with the standard blocks.  

For this project, I’m staying in the realm of configuration.  I will use automation like process builders, workflows, etc, but I am not going to utilize any code.  This is my favorite way to develop in Salesforce by the way- I love the challenge of finding a way to declaratively meet a requirement!  I admit, there are times that code is the way to go for various reasons but every good admin and dev out there know the more you stick to the standard features, the better you are off long term to take advantage of the ever evolving platform.  

To begin, I like to start with a whiteboard.  I like to visualize the different components of the system and processes I’m looking to build.  It helps me determine the best path forward.  This is where experience and analytical skills come in, especially if you’re not leveraging Salesforce for a traditional Account/product/selling/etc application.  

Here’s a picture of my initial notes when thinking through what I want to do:

So my first thoughts are:

  • What do I want to track?
  • What are the different components to consider?
  • Do I have a structure in mind in how these all connect?

What I have in the photo are notes- it’s not a commitment.  It’s purely first steps in brainstorming as in this case we’re going outside the standard Account based model in terms of what we’re tracking but we are going to keep to the philosophy of using the standard functionality and see if we can model what we’re wanting after the account model.  
Before I go any further- as this is purely a fun exercise, I am going to focus on Magic Kingdom park of Walt Disney World.  It is complex enough on it’s own to give us a lot of data and options to consider for our app.  Plus, if you’re going to WDW, you’re going to go to Magic Kingdom. I don’t know anyone who skips this park during their visit!

Next thoughts and questions:

  • How does MK fit an account model?
  • How granular do I want to be?
  • What components do I want to focus on for my MVP (Minimum Viable Product)?  (More on this in another post)
  • What are my questions about the component experiences?  Why am I interested in tracking any of this information?
  • Recognize that I want to be able to update via Salesforce1, so mobile is a consideration in design.

That’s a bit to ponder about for now— there’s lots of other questions going on in my mind as to design, what information I already have access to supplement the detail records, and any apps I may be aware of I can install to help me reach my goals.  Just tossing this out there, but do I want to consider tracking time in lines?  Crowd information from various sites?  Posted wait times versus experienced wait times?  

If you have any ideas or considerations, feel free to share them in the comments!  

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: