Changing the way Salesforce Admins and Developers think about client solutions.

The Wife App

So this site has been in the works awhile but hasn’t quite gotten off the ground because just as I came up with the idea for this blog our first baby decided that it was time to enter the world, due date be damned.  Once things settled down and I started talking to her about it, she said it would be great if I could build something for her as well – she didn’t like the apps that were available.

This got me thinking:

  1. Developer Orgs come with two full licenses, and I can always move her to platform if needed
  2. It can’t be that hard, it’s just nursing and diapers at this point
  3. I can scale her profile and capabilities moving forward
  4. It’s a good opportunity to go over some security settings that are worth discussing
  5. This way I can spy on her remotely

I see no downside here whatsoever so I got to work.

Since she’ll be (she says) “busy” most of the time, this has to be mobile first for sure, and as easy as possible.

Profile: Wife Profile

This is one of those scaling considerations that you want to think about prior to building new objects, fields, etc.  I quickly determined that I wanted my wife under a different profile for a few reasons, all of which can be thought of in business terms as well.

  1. I didn’t want her messing up anything else I had done
    • Business: Don’t make everyone a System Administrator
  2. I didn’t want her accidentally deleting all of her work
    • Business: They’ll start deleting things they shouldn’t if you let them, especially right after Go Live because they haven’t learned yet and will make mistakes
  3. I didn’t want her to be bogged down with other objects she didn’t need to see
    • Business: This is different from security.  This is about having a clean experience for her.  Salesforce1 especially is much more Tab driven than App driven and as a result she’ll see all the tabs she has access to, and it will be confusing.  I’m better off creating a new profile and keeping it really simple.  Again, think about scaling up your company, lay the groundwork first.
  4. Future scalability
    • Business:  As with everything, this gives me the option to grow my org further without constantly worrying about what she can see and what she can’t.  I can build this out moving forward while always keeping a “wall” (if needed, don’t tell her that), between my work and the stuff she needs.


Put up your hand if you’ve built something without checking what the reporting requirements are first.

Everyone can put their hands down now.

Always, always, always find out how people are expecting to report on what they are entering.  This needs to be done prior to building the application.  I don’t need the business to parade out the 20 reports they use (they’ll try to do that), but I do need them to explain how they will look to report on things moving forward.  Examples as to why:

  1. Picklists vs Lookup objects – Even if picklist values are exactly the same across multiple objects, Salesforce doesn’t think that way.  However the business will assume that will work.  Don’t put what you might think of as a “Universal Picklist” and expect good reporting – you’ll need a new object for this
  2. Details – Find out what key details they’ll need.  This will help guide your required fields and also any validation and workflow rules
    • Try to make fields required on the page layout, not at the database level.  This annoys developers
    • Workflow and Automation in general are those often forgotten Phase 1 items that the business will try to ignore until Phase 2 – which may or may not ever happen.  Getting them in as part of Phase 1 helps change the discussion from business requirements to solving problems – which you’ll want to do
  3. Unnecessary Details – In general, don’t make things required that won’t be reported on.  Of course there are exceptions, but the goal is not to duplicate the level of entry required for your ERP system.  It’s to get good information in, and get it in quickly.

Moving back to the discussion with my wife, she told me what she was looking for and what information would be required.  I didn’t care at that point what kind of graph she wanted, or what timeframe she wanted for a bar chart, I just needed to know what the data points were that mattered.

At this point I was ready to build the app, at least as a proof of concept, which I’ll go through in my next post

Share Button


  1. Never thought of using the reporting requirements first before creating a new object. Definitely taking this away with me next time I create a new object

    • geoffreyflynn

      January 9, 2015 at 2:55 am

      You really have to, otherwise you’ll almost certainly end up in a situation where a user doesn’t understand why having the same picklist values in a field in two separate objects doesn’t mean they can join a report based on that field.

  2. Love it! Did she try it?

    • geoffreyflynn

      January 8, 2015 at 3:44 am

      She uses it every day. There was admittedly a retraining session once I ran some metrics on usage, but since I also built the dashboard for her she realizes the value of entering all her data.

Leave a Reply

Your email address will not be published.


11 + 14 =

© 2018 ExploitedDevOrgs

Theme by Anders NorenUp ↑