Author: Mary Reiner

Now that your company has rolled out its shiny new CRM system, you’ll want to make sure your team is fully on board. How can you track Salesforce user adoption? What are the signs you don’t have full buy-in from your organization on using Salesforce?Silhouette of many thumbs up Of course, there are many useful reports available in the Salesforce Adoption Dashboards. To get the most benefit from those dashboards and reports, you'll need to quantify your expectations. How should your team use the system?

3D stick man jump over crack floor, business concept, avoid pitfalls.Working with Salesforce relationships is a little different from traditional relational database structures, but Salesforce has great tools for building custom data relationships and most people can adapt quickly to the SOQL model. As with any other system, though, there are a few "gotchas" to watch for when designing Salesforce relationships. I ran into one of these gotchas just recently. I needed a lookup relationship from our custom object to the standard Product table, Product2. No problem, right? Create the lookup field in the custom table, and there it is. Not so fast!  

Data Charts It's a funny thing about Salesforce developers. Many of us really dislike change, even when we know very well it's necessary and worthwhile. Why? Too often, changing an application is like re-routing plumbing after the house is built: making a change that looks small can take a whole lot of effort with a whole lot of risk for collateral damage.

It's easy to assume that someone needing user support is not using the application correctly. What if there really is a bug?

We've all seen the acronyms from user support techs: ID-10-T errors, PICNIC, PEBKAC, and so on.User support, catching bugs On the one hand, they're pretty mean-spirited (but kinda funny). On the other hand, who can blame user support techs for being exasperated when rude, frustrated users scream at them to solve problems that aren't their fault. Yes, some support techs really do have to walk users through the most basic of operations. REALLY basic, like making sure the computer and monitor are plugged in and powered on. On the OTHER other hand, it is the job of support techs to bridge that knowledge gap. As consultants, we are often called upon to support our own or someone else's software. We have to be the opposite of that acronymic stereotype. Users aren't idiots; they're experts in something we are not proficient in and vice versa. Once in a while, we are on the receiving end of user support, and these experiences can be real eye-openers. I remember one instance where we found an undocumented limitation of a mature third-party application.

DISCLAIMER - this article applies to mainly to Organizations without business analysts and programmers on staff. A few years ago, we were asked to quote a small automation for an existing, repeat client. They wanted help streamlining a spreadsheet-based process that took about 1/2 day of a high-level employee's time each week.

Client: Can you help us save some time by writing some Excel macros?

Susco: Of course we can develop some Excel macros for you. But first, why do you need them?