I’ve just discovered that our custom Invoice templates that we had defined in Office 2007 / 2010 no longer work in Word 2013, when we try to export an Invoice the XML is left in tact. Editing the template yields:

I’m sure that anyone who has used SQL Server Integration Services (SSIS) for more than a day has hit this really annoying ‘feature’. The problem is basically that the source / destination of MS Excel in SSIS defines all strings as Unicode. If the table you are importing to or exporting from has non-unicode (e.g. varchar vs nvarchar) fields then you’ll see error, after error saying “cannot convert between Unicode and non-unicode…”. The solution is to use a Data Conversion transformation however this is extremely tedious especially as it changes the name of every column and requires click after click after click to do something which frankly should be implicit or at worst automated.

Below is a variation of a naming convention that I use within database and Salesforce.com systems that I manage, to be clear I am talking about the API name or underlying table names and not the labels that are exposed to users. I would like to stress that the most important thing is to have a naming convention what that convention actually is is of secondary importance. You will know that you have a good convention when you get the field/API name correct >90% of the time without actually knowing the table well simply because you know how it would have been named by its purpose.

Name your fields

If you’re reading this then you’ve probably already determined that you need to think about the naming of your fields. On a new field creation Salesforce.com first asks for the label. It then creates an API name based on this label, thus you can get:

Note that the spaces and apostrophe all become underscores making the ‘s’ stand on its own and the API name overly long (those underscores aren’t helping us at all). Also if the label changes (e.g. “2”->”two”) then confusion ensues as using this ‘convention’ the developers will always assume that the API name matches the label.

“CamelCase (also spelled “camel case” and sometimes known as medial capitals[1]) is the practice of writing compound words or phrases in which the words are joined without spaces and are capitalized within the compound — as in LaBelle, BackColor , or iMac. The name comes from the uppercase “bumps” in the middle of the compound word, suggestive of the humps.”

Try to avoid using abbreviations unless they are very widely used i.e. Id is fine instead of Identifier, Pro_Serve is not a good abbreviation of Professional Services as it is not consistent in its number of characters for each word and “Serve” is not a known abbreviation of “Services”. See later about verbosity in naming. Acronyms are treated as if they were words, so SFDC Account Id would become SfdcAccountId – whilst this one isn’t intuitive it is necessary to properly separate the words out correctly. If SFDC were treated as all capitals many tools would (like SSRS) convert it to “S F D C Account Id” which is ‘more’ wrong. In this example “SalesforceAccountId” would be best.

Grouping

The underscore (_) character can be used after a field prefix to logically group fields together for example:

This grouping means that when fields are sorted alphabetically logically related fields appear together, very useful in implementations with >150 fields. Grouping is easily achieved by slight word re-arrangement for example; although we would usually verbally say “Date Created” here we name the field CreatedDate.

Grouping (underscore) isn’t absolutely necessary for field ‘pairs’ for example CreatedBy and CreatedDate or Contact.AccountId and Contact.AccountType (as the two fields will always be populated together). However if you anticipate other fields being added to this theme then grouping can be beneficial and makes reviewing the column/field list much easier.

Choice of words & Verbosity

This only outlines the conventions for naming, the actual choice of words is a task best proposed by one individual and then reviewed by others to ensure that the words are a good reflection of the purpose of the field without extra clarification. It is very rare that an individual gets the naming right alone. Bounce the ideas and then finally have the actual text review for typos (!!!).

However great the temptation to “quickly create a field” you should always resist, spending literally a few minutes carefully considering the naming will at a minimum save you time later and more importantly prevent a field being misinterpreted and thus wrong business decisions being made.

Remember it is better to be unambiguous and have a long field name than a short field name that is open to interpretation. If a developer complains that it takes too long for them to type a long field name then I’d suggest they’re in the wrong profession if they struggle typing a dozen extra characters.

My mum has recently been given a D-Link DIR-615 wireless-N router from Virgin Media with firmware revision V1.00VG and HW revision D4. This was working fine until today when I tried to VPN-out using standard Windows Networking and got it hanging at “Authenticating Username and Password”.

It appears that this is a common complaint with Virgin’s firmware and at the time of writing (9 Jan 2011) no updated firmware is available to resolve it. I’ve searched various forums and found no solution, my guess is that it is NATing the TCP1723 but not passing through the GRE.

I solved this by using the open-source DD-WRT firmware which I put on all of my routers (Buffalo / Linksys) usually anyway. I hadn’t done this previously as Virgin won’t support it and if it breaks most likely won’t replace it either – you’ve been warned. On the flip-side the last equivalent router I bought (Buffalo) was £22 from eBuyer so I wouldn’t worry too much if you need to buy an equivalent to replace it.

Steps to get it working (correct as of 9 Jan 2011) – print / save this page before getting started!

Enter “DIR-615”, click the HW revision that corresponds to the sticker on your router

Download the “factory-webflash” file to your harddrive

Now, using a wired network connection go in to maintenance and upgrade firmware. Specify the file you just downloaded. Note you can use a wireless connection but it’s safer to use a cable.

After a minute or so the router will be flashed with the DD-WRT firmware. This means that all of your settings will have been reset. If you are connecting wirelessly then a network called dd-wrt will appear with no password which is your router

One of the many advantages of modern CRM systems is that it is very easy for business users to add additional fields. One of the main disadvantages of modern CRM systems is that it is very easy for business users to add fields without giving thought to the ‘bigger picture’. In this blog post I will discuss my approach for determining when to remove that field from the system.

If you don’t read any further than this the basic principal is that when a field is no longer trustworthy there is point keeping it in your production CRM system.

Can we trust this field?

What do I mean by that? Well a field is untrustworthy if you (and no one else) can’t find a consistent process for populating or maintaining that field despite reasonable efforts to do so. Let’s take an example of an ‘Account’ field that says “Number of Employees locally”:

Who collects/populates it? Is it the Sales Rep? Is it the marketing department ? Is it from a 3rd party data provider?– Don’t know and can’t find out? – back it up and delete it!

When is it collected? At time of record creation? When the Account becomes a customer? When there’s an opportunity?– Remove it

When was it first ‘put into production’? This is vital if we are doing any kind of historical analysis.– If the field is only there for trend analysis, the data appears patchy then it’s useless.

When was it last updated? What’s the worst case?– no historical value? lose it.

Do we actually understand what the field means? Is it unambiguous?– it’s useless

Do we understand what the field means?

I will write a follow-up post on field naming conventions, however what we must do is look at the field name / label and determine if the question used to populate the field is at all ambiguous? Even if the IT/IS/Sales Ops department understand the meaning of the field do the people who are actually populating it? What about users who primarily speak different languages?

An example of an ambiguous field I saw recently was on an account and just said “MSP Customer” where MSP means Managed Service Provider. Due to my client’s channel sales model it was not clear if this field meant the account was a “Managed Service Provider” themselves or if this account was effectively an indirect customer since they purchased through a Managed Service Provider.

What is the purpose of having a field anyway?

I think that this is the most important point, we create a field for either (or both) of the following purposes.

To mark a record as being at a certain stage in a process.

To record data for later analysis (reporting).

If a given field is not adding any value to a current business process and it has no historical value for the reasons listed above, back it up and delete it before someone makes a business decision based on its content!