The issue relates to disclosures. In a real estate transaction you have lots of disclosures but they are written and reviewed prior to or during the visit to the Escrow office.

What happens when many of these need to be conveyed over the phone and then archived for future reference? What if they also need to include order specific information such as pricing or quantity information? Additionally, how do you insure that updating the compliance script in the future won’t overwrite previously saved versions that are only valid if kept as they were read originally?

The last requirement is the most important and challenging one to implement, especially in light of custom information to be included within the text to be read to the client.

The first option many would choose here is to use text formulas which work great for simple statements that will have minimal or insignificant changes in the future. However, since changes to formulas are global, they must be changed with care as they will automatically update previous records and leave no trace since formula fields currently can’t be included in Field History. This will work for some but certainly not all as legal language will have to change over time without overwriting data on previous records.

The best option is to separate all the necessary information into simple descriptions that have custom, order specific data that use formulas such as:

 "Your order today, December 12, 2010, will be for $58,434.92."

and more detailed disclaimers and proscriptions that use field default values such as:

"You understand that the purchase of physical precious metals does 
not pay dividends, interest, or earned income and may lose value."

Salesforce.com Field Default Value

By using field default values for the key aspects that are read to the client, you avoid the issue of overwriting by field updating as changing the field default value only affects future records, not previous ones. The formula values will update previous records but since they are simple and descriptive when done correctly, it will be insignificant.

I provide 15 minutes of free advice for first time callers to prove my value. Schedule it here.

Happy new year.

I hope this is one of those simple examples. Please let me know otherwise below.

Workflow is a feature of the Enterprise Edition of Salesforce.com that provides a lot of that powerful but daunting flexibility.

I am going to focus on a simple but valuable way to use Workflow to make your data more consistent and readable. I will then show a few screen shots as examples of the setup process and then offer a few additional ways this could help you.

You and I have a different way of taking notes. You probably write very well. Me, not so much. I use pictures (thanks Tony Buzan!) and you use abbreviations. I oscillate between ALL CAPS and Camel Case (also called Title Caps) and you write in all lowercase.

So, let’s say we are both working together on a deal in Salesforce.com and logging calls, tasks, updating Opportunity and Account information, etc. Our style of writing will start making the information look strange. Certainly my doodles would be absent but my ALL CAPS, Title Caps, and your lowercase notes would certainly stand out.

Many companies require all written forms to be filled out in ALL CAPS due to the variance in how people write letters like o, i, l, and others. It is probably a good idea to set the same rules for information that is typed in since all are used to looking at capitalized letters.

Workflow can do this automatically so no matter who enters valuable information, it will be placed in the right case when it is saved. All we have to do is setup a simple rule with some actions and it will all happen automatically from there.

Inside the Salesforce.com Setup area (click the “Setup” link at the top, just right of center), we will navigate to Setup | Create | Workflows & Approvals | Workflow Rules. Click New Rule and select what object it relates to. In my case, I want Account fields to be saved in ALL CAPS.

After clicking next, choose the criteria of your rule. This is just Salesforce.com asking, “when should I do these actions?” I chose every time the account is saved and when Account Name not equal to null so it will run every time it is saved, whether a new or existing account.

By clicking Edit on this screen, you can add/modify the actions you want to execute when the rule gets invoked.

In this case, we just want to take some existing text, such as “Hello world!” and make it “HELLO WORLD!” before saving it. We do this through a Field Update as we are updating the text that exists within a field.

Here is the simple formula that transforms text into ALL CAPS. You can use this exact syntax for each field as long as you just change the part that is inside the parenthesis to be the specific field you want to change. Use the Insert Field button to pick one and it will insert it into your formula for you.

Once you have done this, simple go back to an existing Account record, edit a field and save it. If done right, all the text fields you assigned actions to will automatically turn to ALL CAPS. The page will be SCREAMING SUCCESS TO YOU!

I’m not angry, I’m excited. Really.

To your success.

The Test

1. Do you have at least 2 versions of the same form and have difficulty getting your team to use the right one?
2. Do you let your sales reps come up with their own method to manage leads?
3. Do you only hear of a deal once it’s been signed?
4. Does your staff complain of too much “admin” or “overhead” time?
5. Do you have an employee that manages docs and spreadsheets regularly?
6. Do clients complain that their expressed needs were not met or items were forgotten?
7. When a sales rep departs, is their little hope of finding, not to mention working his in progress deals?
8. Does your sales manager have little visibility into your sales pipeline (i.e. accounts, deal size, win rate, discounting)
9. Is there little historical data available without significant manual labor?
10. Do you often have to search through numerous docs and emails for account related info?

Each ‘yes’ answer on this list is shaving hundreds of dollars from your profitability for each employee!

The flexibility of these tools is very helpful at times, especially when doing one-off tasks or exploring a process. However, when you are looking to grow and add on additional resources as needed, this flexibility puts too much creativity into the hands of each person and leads to an organization headache with lots of confusion. Especially if the situation isn’t changed before the next growth spurt.

The worst time to change is when potential customers are knocking down your doors.

The Solution

Most businesses make the decision to move away from this flexibility toward a manageable system when they are small and want to grow. Profitable growth is very challenging in general and without a simple, consistent system to manage the increase of very important information, it can be stunted.

My recommendation to any business that answered ‘yes’ to at least one question above is to consider starting with Salesforce.com Group Edition. With a free 7 day trial and just $8 or so per user per month for up to five users, you can see quickly the benefits of having a common system for all your team.

Salesforce.com is a great place to keep these numbers. However, if you create a custom field and store them as numbers you will find your formatting probably will not be allowed or preserved.

A couple examples:

• US Tax ID numbers are in the form of: 88-8888888. This number contains a dash after the first 2 digits. Social Security Numbers have the same problem with two dashes: 888-88-8888. Not allowed as a number with the dashes so you are forced to enter in the numbers by themselves, removing the intended formatting and giving you a new format: 888,888,888.
• An account number with a vendor is 8847506644758 and can be saved as long as it is 18 or less digits before the decimal. However, when you view it, it shows 8,847,506,644,758 which is a little distracting to the eyes and confuses the fact that this number is an account number, not a numeric total of something else.

The solution in both of these cases is to only store numeric data that will be related to calculations in formulas, reports, etc. There will never be an example of subtracting two SSNs or adding merchant numbers together so storing them as numbers, even though they are, is unnecessary and cumbersome.

The rule should be:

1. Only store numeric data as a number when it quantifies something.
2. Otherwise, use text and include any spaces, dashes, or other characters that make it more easy to read and parse (i.e. 66898-9865-57377)

– Jon