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

Wine App Part 2 – Fixing My Mistake



As I touched on a few weeks ago, one of the great things about a developer org is that no one is around to see you screw up.  The problem with this plan is that when you blog about what you are planning to do before building it, people know that you screwed up.  For people who haven’t been down this path before, welcome to prototyping requirements.

If you missed last week’s post, I introduced my plan for a Wine App using Salesforce.  My plan was to build out objects based on this approach:


The problem with that approach, as I found out today, is that you can’t have a detail object underneath a junction object.

A junction object can’t be on the master side of another master-detail relationship.

Now I could do it as a lookup, but it got me thinking why I needed to.  I could think of a few options

  1. Create as a lookup instead.  And have a report type that is “Consumed Bottles with Wine Purchases”?  I don’t think so.  Not a fan of that approach.  This is practically the definition of a master-detail relationship, it just doesn’t feel right
  2. Take off the Wine Cellar object so that Our Wine Purchases isn’t a Junction object anymore.  I don’t like this one either, at least not yet.  I think that the Wine Cellar is an important unifier to everything we have.  It exists, it has its own characteristics, it should be included.  Maybe down the road I also want to track heating and cooling costs over time compared to how many bottles are present at any one time.  Trending anyone?
  3. Why do I even need the Consumed Bottles object anyway?  What if I could just leverage Activities instead?

So it’s number 3, using Activities, that I have settled on for now.  But in order to make this work I need to do a little bit of work.  Since this issue came a little bit out of left field, I’m still not trying to finalize every field, but “pivot” my thinking to a different option and therefore still just a revised prototype.

Here is my current Wine Purchases page layout



You’ll see that I’ve created a Total Consumed field and then I’ve also got a Remaining Inventory field that is just a calculation of Quantity Purchased – Total Consumed.

So now two things need to happen

  1. We need to easily enter Consumed Bottles as Activities
  2. We need to Roll Up activities onto this record

Entering Consumed Bottled

I could absolutely use the Log a Call button if I was lazy

I could also do a custom URL hack button called something like “Log a Bottle”.  I’m sure I’ll use this at some point but for now the link will point you in the right direction if you want to try one yourself.

I could create a new publisher action.  I’ve done this a few times before, but I go into the most detail in my article on mobilizing mileage tracking.  The key here is that this action is unique to the record, it is not a global publisher action, so I’m actually creating it under the Wine Purchase object and I’m calling it “Drink a Bottle”


Note that I’ve set most of the Activity fields as pre-defined because I want it to be as simple as possible.  After all, drinking a bottle of wine should be pleasurable, not a chore.

After that’s done, it’s as easy as clicking the action right on the page and entering the Subject and Comments.


I’ll refine the Activity portion over time but for now I want to make sure this will work.

Rolling up the Consumed Bottles

Ever tried rolling up Activities to their parent object?  Ever been really annoyed because you can’t, but your boss thinks that there must be a way, you just don’t know it yet?  Ever tried rolling up any Lookup relationship only to find out you can’t, and then trying to make it a master-detail just so that you can roll it up?  Annoying yes?

Behold Declarative Rollups for Lookups by Andrew Fawcett (twitter)

Also known as one of the most useful apps you’ll come across.  You can read more about them here, or here

Install them, have them ready for just such an occasion.  I’ll save you the full explanation of setup but rest assured once you do it once it’s a 5 minute job to set up the next one.  Here is my configuration:



Honestly, it’s really easy, you just need to know the API names.   Get this up and running and you’ll be rolling up Activities onto any record you want.  In this case, I’m now able to:

  1. Enter the wines I’ve consumed using the Drink a Bottle publisher action – which also works on mobile of course
  2. Track my total consumption of a wine by rolling up the activities
  3. Do a true Roll-Up to either Wine or Wine Cellar objects with a SUM of Total Consumed across all child records
  4. See remaining quantity using a simple formula field
  5. Actually build what I wanted to build, quite possibly better than before


Deep down I knew that something just didn’t quite seem right, whether it was that object, the Cellar object, or just a general sense of over-building, but it took me building the app to actually figure out where my mistake was.  So not only was this a good way for me to try something outside of my work account, it was also a way to learn something new and be better for having tried it.

When you start getting into customization and building to what clients want, prototyping becomes an important part of what you do.  It doesn’t need to be perfect, but you need to know that it works.  Fields can come later, make sure the objects, and any cross-object requirements work.

The key is to not say something is possible per how they describe it unless you are 100% sure.  I’ve made that mistake too many times to count.  Want one?  Try assuming you can always send an email alert to the Owner’s Manager.  Go ahead, try it without another workflow to set that field on the record on creation and edit as a hardcoded email.  Better yet, don’t figure it out in a dev org and just tell the client it isn’t possible, only to realize it’s possible less than 2 weeks later because you didn’t think to ask on the Success community right away.  Not that I’ve ever had that happen to me.

Last thing on prototyping – be very careful about reusing any fields you have used as part of the prototype.  To often you race through page layouts and field level security – you know, the last two steps every time you create a field – in the interest of time.  If you use them in the final product and haven’t reviewed that they are accurate, that will come back to bite you.  Want a better way?  Use your dev org.

If anyone has done something similar to a Cellar another way feel free to leave it in the comments.  Having an object for a single record still feels a little funny to me but as of now I still think it makes sense.  Maybe in my next house I’ll have two cellars.  Scaleability is important when it comes to wine storage and consumption.

Share Button


  1. I love the concept of this blog – true dogfooding!

    Re: the issue you have with the consumed bottles vs wine cellars I think I would favour one of the following options:

    1. Change the relationship from Our Wine Purchases to Wine Cellar to be a lookup relationship. This makes more sense to me anyway – your purchases are being stored in a cellar but should you move house they would move cellars if you took them with you. The cellar isn’t a fundamental property of the wine purchase. I read through the reasons you didn’t pick a lookup field on your other post and I know you don’t like the name of the report type and you want to use roll up summary fields, but I think all the data you would want will be available more easily through reporting rather than roll up summary fields.

    2. Simpler solution: cellar could be a picklist on Our Wine Purchases. Maybe called: storage location. This will scale fine to a small number of cellars (say 15). The stats around red vs white etc would still be available on reports.

Leave a Reply

Your email address will not be published.


3 + 14 =

© 2018 ExploitedDevOrgs

Theme by Anders NorenUp ↑