Post Published on December 9, 2010.
Last Updated on November 29, 2017 by davemackey.

I spend a lot of time using and configuring FrontRange Solution’s GoldMine CRM software. I’m not claiming to be an expert in the software – in fact, if you travel over to the more frequently utilized forums related to GoldMine you’ll see I sometimes get taken to task for asking seemingly simplistic questions. But, as someone who is involved from a systems administration side and is still a n00b in some senses, I thought my perspective might be worthwhile.

This is a living document. I plan to flesh out much of the brief points here.

The Good

• Utilizes Microsoft SQL Server on the back-end.
• The User Interface is fairly intuitive.
• The User Interface is highly customizable, allowing it to be customized for any type of organization/business.
• Automated Processes allow advanced automation and scheduling of tasks and communications.
• Keeps detailed history of changes made to records.
• Allows for a number of interesting updates – for example you can update a field to be “proper” which will attempt to take something like DAVE MACKEY and turn it into Dave Mackey.
• Includes a 5-digit zip code database with the product.
• Allows for one-to-many records that can be associated to a contact, this allows you to do things like associate multiple people, phone numbers, addresses, etc. to a single contact ad infinitum – e.g. you are not limited to a hard and fast number (only three addresses, and so on).
• Lookups allow you to force data entry to occur with only certain values and to assist data entry in occurring faster by providing auto-type as an individual enters data.
• You can see how long people have been logged in, if they are idle, if they are actually doing anything, and so on.
• Integrates with Microsoft Office – including Word, Excel, and Outlook.
• Can integrate using Computer Telephony Interface (CTI) with your phone system.
• Numerous plugins and addons are available to extend the functionality of GoldMine.

The Bad

• Ummmm…Why did you just crash? 🙁 Again?
• Shows you each email it is sending – and won’t stop – which becomes a hassle if you are sending out a lot of emails.
• If you “curtain” a record (that is, prevent people from seeing certain aspects of it) the individual can no longer edit any aspect of the record.
• There is no option to “Add User From” field in Auto-Processes when sending emails (which is odd, b/c there is almost everywhere else in Auto-Processes).
• You have to create multiple events within an AP to handle multiple actions off the same event. It’d be nice to design one event that then has multiple actions – would reduce redundancy.
• There is not granular abilities to restrict data at the UI level (one can do more at the database level). This makes it difficult to prevent people from entering invalid characters or values into a field – this could be easily fixed with validation, which is a common feature in most products.

The Ugly

• In database theory there is something called normalization. This is considered best-practice and involves (amongst other aspects) dividing tables into logical divisions, e.g. rather than having all your columns in one table (like name, address, state, city, zip, phone, age, birthdate, and so on) you divide them into logical tables with “keys” (unique identifiers) that can link between the tables to make one big view when needed by the end user. Unfortunately, GM throws this idea out the window in several significant areas – namely the core contact tables CONTACT1, CONTACT2, and CONTSUPP. CONTACT1 and CONTACT2 should be divided up into a number of tables like – person, address, phone, email, and so on – instead of all being lumped into one table…but this is livable.
• The really annoying part comes with CONTSUPP, which is used as a “catch-all”. Looking for an additional contact associated with that contact? Look in CONTSUPP. Looking for an additional phone number? Email address? Company? Look in CONTSUPP. This even would be livable except for the fact that the column names in no way reflect the contents of the columns, thus while the column name might be “Zip” it may actually hold a phone number, and while a field may be named “Contact” it may hold a phone number, and so on. There are “header” records (also in CONTSUPP) that you can use to “decode” all of this, but still…this is bad, really bad.
• Another bad design concept is the account numbers. Rather than using integers as most do – like 1000471812 and so on, they utilize a complex combination of values from each contact record that give you a accountno that looks something like A78294VB~$%. Several of these characters are reserved in SQL which means that if you aren’t very careful your script may do something you don’t expect.
• The application utilizes DDE – a very outdated data sharing methodology. While they discourage in their API documentation third parties from using DDE they still have it enabled by default and the Microsoft Office plugin is built on the DDE technology.
• The pricing isn’t out of line with many other CRM providers who have been around for a while – but it is certainly out of line with many of the newer entrants and SaaS solutions.

Would Be Nice

• You cannot delete the USERDEFxx fields which are auto-created on CONTACT2 and which you usually don’t use (you can create your own user defined fields with descriptive names instead).
• Would be nice if it supported record types beyond character, numeric, and date such as BLOB and boolean.
• Cannot resize the User Defined Fields window.
• Ability to edit all User_Var values through GUI – rather than ini files.
• Since it was originally built on dBase it offers very tight integration with many dBase language features but only decent integration with MSSQL features.
• Movement of the INI, TBI, and BIN files into sub-directories within the GM directory to help declutter.
• Right now you have to manually create preview images of reports, it’d be nice if this was auto-generated.
• The ability to “undo” steps in the Expression Builder. Right now if you accidentally make a make a mistake you are out-of-luck and have to do all hand editing from thereon out – or clear the expression builder and start again.
• If a document is queued by an AP and and then the AP is dropped, the document remains queued. There should be an option to have it removed.
• The ability to have a different name for an email template than for the subject of an email.
• Support for all merge fields in the email design interface.
• The ability to copy/move events between APs.