Building a Better Mouse Trap

I’ve been looking forward and a bit hesitant to make my first technical post but it’s got to happen sometime. It’s not a ground breaker and honestly I don’t expect to post at that level. I wanted to share some of the things I come across that I think are cool or may help someone else. I’m not saying it’s the right answer or wrong answer but it is an answer that I arrived at. That’s the wonderful thing about SF.com’s user community – we love to share.

One great aspect to being a solo admin is that you get to wear many hats in the role – Project Manager, Business Analyst, Administrator, End User, Data Analyst etc., etc. which is why I picked this little tidbit. It illustrates how a very simple and benign request can be built out into a more functionally rich solution by putting on those many hats. Sometimes the simplest answer is the right answer and other times you can just do better! Hopefully what you end up with is a user who sees their idea put into action beyond their expectations that can serve many other users equally well. Enjoy!

Initial Use Case –

We would like to identify companies that may be at risk of for timely payment so I have made a note on their account for upfront payment. The problem with that is we create (or should create) our opportunities through the contact, not the account, so people might not see this note when creating opportunities if they go straight to a listed contact.

Is there a way that if there is a payment history payment with a company and a note has been made to the account that this can be highlighted on each contact against that specific account?

Thought Process –

Users are not accustomed to reading through record notes and looking for this type of information. It’s just not how we normally operate so using Notes was not the best solution. Adding a simple text field to a contact record that appears at the top of the page would have partially met the request but only at a single contact level. That is not optimal if you have a client with dozens or hundreds of contacts.

Looking at this from an ease of use angle, it’s a lot more efficient if I can update or display this information on each contact related to the account for the user. I opted to force the entry to occur at that account level so the changes flow down to all related contacts. A single new field on the contact would be read only. The nice part about the contact getting its value from the account record, Text (Account.Payment_Advice__c), is that any new contacts added after the advice is entered would display the correct advice information immediately without any additional processes required.

It occurred to me that as a user who opens an account and sees negative payment advice that I would want to know who flagged the record and when. Is this timely information and who can I follow-up with for more detail?  You can use history tracking if you have fields available to track left but a) there are only 20 and we used them all and b) users don’t want to scroll to the history of a record and read through it for information. There can be a lot of history to troll through.

Solution –

Create a set of fields and process that allow a user to record payment advice that will appear on the account and appear on the related contact records while capturing the recording user’s name, date the entry was made and make a post to Chatter.

THE FIELDS

•  Add Picklist Field to Account – Payment Advice

Values –

1. “No Payment Issues” or
2. “Negative Payment History – Upfront Payment Recommended

• Add Email Field to Account – Advice Added By

Email type was chosen as the value will be the $User.UserName which an email address. I did this so a user, could if they wanted to email the person that set the Advice, click the email and pop up and email window. Little bit of a workflow benefit.

• Add Date Field to Account – Date Advice Added

• Add Formula Text Field to Contact – Payment Advice

Field is read only at contact level. Values – value recorded on Account.

The Process Builder

This process is kicked off when a user CHANGES the value of the “Payment Advice” field. Nice and simple. The values for the Date Advice Added and Added By are updated with the Update Record Option.

The Result

The user makes one selection, Payment Advice, and the newly added related field’s auto-populate after saving. The same advice note is now listed on the contact.