You are here: Home / Archives for Salesforce

Beware of the Salesforce.com “Integrated” label

February 21, 2011 By Leave a Comment

I’m coming across more and more business applications that clame they’re “integrated” with Salesforce. The other week I was presented with a system where the “integration” was part of the implementation package. However, the vendor knew nothing about our environment, and based on the use case of the application, they couldn’t possibly clame the integration would be easy.

The problem with the “integrated” label, is that it can mean just about anything. As Salesforce grows, more and more business applications feel they need to say they’re “integrated” with Salesforce, otherwise they risk losing sales. In reality, many of these apps say this despite only half understanding the Salesforce API, meaning they could integrate their application if asked.

Simply put, no integration is equal
You should never accept a vendors statement like “our application fully integrates with Salesforce”, whiteout diving into the details of how that integration works.

So that you can avoid headaches down the road, here are some questions to ask:

Does the application read Salesforce data or does it read and write Salesforce data?
This is by far the most important question to ask. An application that simply reads Salesforce data is the simplest architecture – and is often recommended for initial integration projects. However, at some point, you’ll want some of that data back in Salesforce. For example, QuickBooks reading the data from a closed won opportunity helps make your organization efficient – this is a read only requirement. A truly integrated QuickBooks would mean a Salesforce account can be flagged as having a 90 day past due invoice. This bi-directional integration is when you get true value.

While a simple read / export of Salesforce data sounds simple, don’t under estimate how difficult this can be. For example, if you have an external system that needs to pull the contact details of all contacts associated to a customer account all of the following can make this complex:

  1. Salesforce must accurately flag accounts as customers.
  2. You need to decide if all these contacts really should be sent over (do you really want the details of the accounts shipping and receiving clerk to be integrated?), if not, this is another layer of complexity your integration needs to accommodate.
  3. What is the time frame for integrating records – do you need real time or scheduled.
  4. Does the integration care what products / assets the account has purchased?
  5. This list only gets more complex …

The point is that an integrated application must accommodate your level of complexity when reading or writing Salesforce data.

Is the application on the AppExchange?
The easiest way to guess the quality of an integration is to ask if the application is, or will soon be on the Appexchange. Even a simple data connector listed on the Appexchange must pass an intense security and technical audit. While these integrations are not all equal, it’s a good start to understanding how well the application integrates.

Note: if the application is not on the Appexchange, you must have Salesforce enterprise edition because the integration must use the Salesforce API. Apps on the Appexchange can be installed into Pro, and through Salesforce.com’s new Aloha app program, applications can be installed into group edition. Most “integrated” salesforce applications don’t tell you this on their website!

Does the application write data to Salesforce standard objects?
Believe it or not, this can be one of the hardest things for an integrated application to do. The integration must manage simple things like required custom fields, record types, and validation rules. Remember, if you’ve created one required custom filed, it will cause a write command to fail. To avoid these problems, applications will often install their own custom objects to manage data.

Can the the application read Salesforce custom fields and objects?
Salesforce standard fields and objects are easy to integrate because their API names are the same across all Salesforce instances. However, for an integration to be truly effective, they need to know that custom fileds and objects exist through the use of Salesforce.com’s Meta Data API.

If the application creates contact, account or other records, does it do any de-duplication?
It’s almost too easy to insert records into Salesforce, meaning your integrated application can indiscriminately create contact, account or other records in Salesforce. If the application doesn’t do anything to address de-duplication of records, the lack of data governance will quickly pollute your Salesforce database. If it does de-duplicate, you sill need to understand how the data integrates. For example, does the integration allow you to designate fields that can never be overwritten. You don’t want your good email address overwritten by a disposable email used to fill out a web-form.

Does the application require custom Apex Code to function?
While custom Apex code and Visualforce pages are common to most integrations, you should understand what the code does, and if it interacts with other applications or Salesforce functionality. For example a de-duplication script should be local to the application, and not interfere with every upload you do.

Filed Under: Salesforce

You must document your Salesforce org, but do it right

January 25, 2011 By 3 Comments

Like most people, I always need to fight off the feeling of being overwhelmed when presented with a Salesforce environment that’s been active for many years. The core architecture  is almost always sound, it’s the edge cases that the system supports which worry me.

I’m currently trying to de-bug why I can’t de-activate a user because the user is referenced in an opportunity workflow field update. Of course none of the documentation makes reference, or aludes to the idea that a user is referenced in a field update. This forces me to go through every rule to locate the dependancy … fun.

The problem with documentation.
Documentation is a chore, and we all know that no one likes to read documentation – it’s only referenced anyway. To make it even more complicated, one of the chief benefits of Salesforce is the speed that we can implement changes. All it takes is a simple modification of a workflow rule, and your documentation is out of date.

Inline documentation
We can take a lesson from newer development tools and practices where documentation is written inline with the application code. Salesforce provides us a name, and more importantly a description filed for all fields, workflow rules, templates, etc. It’s in the description filed that you need to document the following.

  • The behaviour of the feature. This is the reason why the feature exists, and is the most important thing to document.
  • The dependancies. If the rule only fires because of some other action, document that action.
  • How the feature works. If you still have the time and patience, document how the feature works. But remember, often all the user needs to do is view the formula to see this information.

Even when we document, we often do it wrong!
We generally document backwards. We tend to document technical attributes of a feature, but not the reason the feature is there. For example, it’s typical to see “this workflow rule sends an email to the account owner”. However, this statement is irrelevant because all I need to do is look at the rule to figure this out. What I need know when I take over your Salesforce account, is why you’re emailing the account manager, not the fact that you are. Your documentation doesn’t tell me that the update is designed to tell the account manager that implementation services are required.

This kind of documentation let’s me quickly respond when someone asks “can we add the CSM team to the notification email, when implementation services are required”. Business people talk in use cases, your documentation should too.

Filed Under: Salesforce

Should Salesforce.com Be On Your Marketing Automation Shortlist?

January 24, 2011 By 1 Comment

I was recently contacted by Lauren Carlson, a CRM analyst at Marketing Automation Software Guide who asked me to give my two cents on this issue. Lauren recently posted her analysis of Salesforce as a marketing automation tool over at the Marketing Automation Software Guide.

In general, Lauren give’s Salesforce very poor marks for it’s marketing automation capabilities. However, I feel Salesforce should always be on your marketing automation short list – but never on its own. Here’s why …

Salesforce is not a marketing automation system (yet)

Looking at Salesforce in isolation misses one fundamental issue. Salesforce currently has no public intention of becoming a marketing automation system. Two of it’s most well known limitations should make this obvious.

  1. Salesforce will not allow an account to send more than 1000 emails within a 24 hour period. Salesforce will explicitly tell you to use one of their many appexchange applications to support these requirements. This is one of the few limitations where you can’t buy an increase.
  2. Secondly, any form of marketing automation has data heavy requirements. Salesforce’s data storage limits causes even small contact lists to exceed these limites, with even moderate marketing activity.

In my view, Salesforce is focusing on three core areas, it’s core SFA functionality in the Sales Cloud (chatter, content, DimDim, Jigsaw, etc.), platform functionality with the Custom Cloud (governer limits, VMforce, Heroku, etc.) , and customer service with the Service Cloud (Cases, Ideas, Portal, Twitter, etc.). Note, I’m putting native applications like Remedyforce in the custom cloud bucket.

How Salesforce supports supports marketing automation

I feel Laurin’s review errors by assessing Salesforce in isolation. Through it’s API, Marketing automation seamlessly fits into Salesforce’s application architecture. (keep in mind that some MA vendors have better integrations)

Sales Cloud – integration with the Sales Cloud allows the marketing user to:

  • Get a complete end-to-end view: from new lead, to closed deal
  • Solicit sophisticated feedback from Sales by implementing a sales accepted lead process
  • Manage named accounts, and ensure leads are routed to quick and effectively
  • Track the purchase activity of all contacts

Custom Cloud – salesforce is generally the database of record for contact information. Salesforce’s powerful developer tools allow the marketer to:

  • Perform advanced data transactions to clean and update records. Including sophisticated custom de-duplication triggers
  • Expose Salesforce data to any external system
  • Support a custom post-sales support process
  • Create custom coded email templates based on the Salesforce object model
  • Website integration, including the ability to integrate with payment gateways

Service Cloud – Salesforce allows you to keep tabs on current customers, allowing marketers to

  • Intelligently communicate with their current customer base
  • Quickly learn if a customer has logged support tickets
  • Determine who happy customers are

Conclusion

In my view, unless you’re a very small business, Salesforce fits into the marketing automation picture by being a central cog in a best of breed application architecture. Typically Salesforce integrated with a single marketing automation vendor. See my post on the 4 ways to extend salesforce to the marketing department.

Filed Under: Marketing Automation, Salesforce

I’m excited to start a new job at Eloqua

January 16, 2011 By 13 Comments

Eloqua Logo

For the past few weeks I’ve been sitting on an announcement that I can now make public. I’m excited to say that today will be my first day as an Eloqua employee.

Working out of Eloqua’s Toronto office, my mandate is to help drive Eloqua’s use of Salesforce.com, ensuring Salesforce is the CRM and development platform we all know it can be. If you know me, or have seen one of my posts, you may know that much of my experience is using Salesforce to drive marketing, and marketing automation requirements. This makes the opportunity at Eloqua truly exciting.

While this is an exciting opportunity, the decision to accept it was far from easy. My time at Architech Solutions was engaging, and allowed me to grow into a well rounded Salesforce solution consultant. In the last two years I’ve had the pleasure of working with 15 clients. From initial pitch, to final project completion, I’ve had the privilege of working on:

  • Two soon to be appexchange apps
  • Sophisticated marketing automation requirements
  • Calculating customer value, LTV, donner lifetime value, lead score, opportunity health, etc.
  • Lead and opportunity management visualforce pages
  • A six figure ERP style custom application that relies heavily on visualforce pages to drive workflow
  • A custom product catalogue that supports a matrix based pricing grid
  • Complex systems integration
  • Multi-year rollout and integration plans
  • Early lifecycle implementations
  • Administrator and end-user training

I’m grateful for the opportunities that I’ve been provided at Architech. I’m now looking forward to bringing my Salesforce experience and perspective to Eloqua.

Filed Under: Marketing Automation, Salesforce

Making your Dreamforce vision, Salesforce reality

December 13, 2010 By 1 Comment

One of the most valuable takeaways from Dreamforce are the customer case studies. These customer success stories give us tons of ideas, and help turn the abstract concept of “running your business in the cloud”, into tangible examples we can all understand. BUT, we often under estimate what’s really involved in truing these ideas into action. I’ve heard countless times, “I need to get back to the office because there is just so much I can do.” But when I look for specific tasks they are actually going to do, I get a blank stare or dazed confusion.

In the past I’ve returned with grand ideas of what I thought would help our business, so I understand the enthusiasm. But I’ve come to learn that if this enthusiasm isn’t managed, we’ll quickly get overwhelmed, causing us to lose track of where to start. Ultimately, this allows the status quo to remain.

The problem with case studies
We need to remember that these success stories are from other companies. Just because they’re doing something doesn’t mean you can implement it tomorrow (or possibly ever). We need to understand that these organizations have a unique mix of culture, people, skill, budget, technology, etc.

Case studies help establish your vision
The reason I love case studies is because they help us establish our vision for the software. But my advice is to use them to guide your vision because only you can figure out what you need to get started. Again, just because another company used a tool on Appexchagne doesn’t mean you’ll have the time, technical skill, or budget to achieve the same results.

Putting ideas into action
Before you get started I suggest you do some form of gap analysis. Here’s what I’ve typically done with clients.

1. Think about what you’re doing today
This means reviewing the systems you use, the responsibilities of these systems, your current business process, how these business processes align with your systems, etc. But, don’t let this become a drawn out assessment by keeping it simple. You just want to understand your starting point. The liberal use of a whiteboard can help with this.

2. Determine what you want to do
You don’t need to be a Visio wiz to do this. Simply make statements of how you want Salesforce to work. I must stress that these need to be specific and actionable tasks. Don’t say, I want Salesforce to manage my post sale activities. Break these activities down into the tasks that need to be done, i.e. send an invoice, assign a service rep to the account, etc.

3. Apply these requirements to Salesforce
Once you have a clear backlog, you’ll be able to figure out how Salesforce will assist you in the completion of these tasks. For example there might be an Appexchange app that does exactly what you need, you may be able to use a simple pick-list field to track key information, a web-to-lead form with a welcome email may satisfy your marketing needs, etc.

4. Prioritize
When you have a clear set of tasks with an understanding of how you’re going to do it, you essentially have an implementation backlog. Now you need to prioritize it! Unless you have a large project team, I suggest you force rank these requirements. This will allow you to start from the top of the list and work your way down.

5. Get to work!
Those validation rules don’t write themselves …

Filed Under: Salesforce Tagged With: ,

Extending Salesforce into the marketing department using email and marketing automation

December 3, 2010 By 3 Comments

In my experience the first step in extending Salesforce beyond it’s native Salesforce Automation (SFA) functionality is to being using Salesforce to drive outbound messaging initiatives. (Unless you do direct mail, this is essentially a fancy way of saying email marketing). Below is a quick overview of the options available to a Salesforce user when investigating the tools to accomplish your marketing needs. Note, the below is heavily simplified!

Native salesforce email
 This is the simplest and cheapest way to begin your email efforts, but it has many limitations. Salesforce limits you to 1000 emails a day, meaning your list needs to be very small. It also does not provide link tracking, meaning you can’t track simple metrics like click through rate, or who clicked on what.

The most meaningful use case for native salesforce email is to support simple triggered and transactional emails, or emails that need to pull complex data from your object model. These emails will let you send thank you emails for signing up on a web form, automated follow-ups from sales, reminder emails for renewals, etc. These triggered emails can also be programed using Visualforce, meaning Apex controllers can pull data from across your data model to populate an email. No matter what marketing automation program we recommend, we often need to use these emails for a clients complex email requirements.

Integrated email service provider
 The most common way of extending Salesforce is through the use of a 3rd party email service provider (ESP). There are a growing number of these tools, and most support simple integrations which pull the contact table, or integrate through the campaign member record. Note: when using these 3rd party tools, make sure your Salesforce data usage doesn’t explode.

I almost always recommend ExactTarget for this kind of mass email. ExactTarget has a much deeper integration with Salesforce than any other ESP. Specifically, ExactTarget integrates with Salesforce reports, and allows filtering by the campaign member status field. It also supports the exclusion of contacts contained in a report. These tools allow you to make very detailed segments.

‘Drip marketing’
If you want to go one step beyond the process of defining a list and sending out an email, you’ll need to look into tools that support more advanced marketing automation, commonly known as drip marketing. Standard uses cases are a new lead welcome program, a defined lead nurturing campaign, triggering an email based on the link a contact clicks on, etc. If your volume is higher than 1000 emails a day, or require email link tracking, you’ll need to look into a more advanced version of ExactTarget, or a marketing automation system like Eloqua, Genus, Marketto, Pardot, and others.

Integrated marketing automation
 Last on the list is a fully integrated marketing automation system. These powerful applications support many different marketing tools that go far beyond email. Tools like Eloqua, Marketto, and others offer marketers: deep and customizable integration with Salesforce, landing pages, email, web analytics integration, lead scoring, complex marketing automation programs, social media, campaign ROI tracking, etc. These tools require significant buy-in from the marketing team as they can be pricey and complex to implement.

Filed Under: Marketing Automation, Salesforce

A simple explanation of Salesforce data storage limits and costs

November 29, 2010 By 12 Comments

Anyone who has worked extensively with Salesforce will tell you that it has many limitations.
A major example of this are the data storage limits Salesforce imposes.

If your Salesforce requirements are particularly data heavy, the limits on data storage will quickly become a major problem. Salesforce.com has implemented a seemingly arbitrary data storage minimum of about 2Kb / record, meaning it only takes 500,000 – 700,000 records to max out the default 1GB (or 20MB / user) most organizations are allotted. With storage space costing about $800 – $1,500 / year / GB, an application that adds 1,000,000 records / year will add $2,000 – $3,000 every year to your bill. Do this 3 years in a row, and your bill can be $6,000 – $9,000 / year higher.

The most obvious example of this problem is an integrated mass email program. If you have a list of 100,000 contacts, and email them once a month, it can add 1.2 million records each year to your Salesforce environment. This will likely make your email marketing program more expensive than you originally thought!

Why is data so expensive?

$1,500 for 1GB sounds crazy when you can go to the store and buy an 8GB flash drive for $10. In my view the cost of data storage is actually about record volume and how they impact Salesforce transaction speeds. When you run a trigger, Apex class, Work Flow rule, RSF, create or edit records, these tasks create transactions that need to be processed by the salesforce.com data center. These operations can get very computationally intensive when your Salesforce environment has millions of records. If there are too many transactions across all Salesforce customers, the system will get slower … for every Salesforce customer.

Multi-tenancy means we all need to get along

Salesforce.com is proud of their transaction speed, and they publish in on their website. Currently it takes about 0.28 seconds to process a transaction. But this speed is maintained through various limits.

In order to maintain a stable environment for salesforce.com’s 80,000+ customers, these limits are necessary to ensure transaction speed can be maintained and kept reasonable. Just imagine if it took 30 seconds to save a record because another customer was processing a job that created and modified 100,000,000 records.

To ensure we all get along in the cloud, Salesforce.com creates these limits.

If it’s about transactions: why the price per GB?

It’s true that charging for more transactions, or record storage would make more sense. It’s my belief that it’s priced per GB because Salesforce.com’s target demographic is the business user. Try explaining to a non-technical business user what a transaction is, let alone charging for them.

Salesforce.com is routinely increasing these limits to become a more attractive enterprise development platform, but for now, my recommendation is to store what’s necessary and pay for it, cleanse unnecessary records, use the API as much as possible to query very large external data sources, etc.

Filed Under: Salesforce Tagged With: ,

Salesforce success metrics that you can actually measure

November 23, 2010 By 1 Comment

When trying to justify an investment in Salesforce, we might think of increased close rate, leads created, etc., as metrics to support our business case. In fact, Salesforce.com likes to use these metrics when selling Salesforce. But, unless “Salesforce” is the name of a new sales person in the filed bringing in sales, the software doesn’t directly increase sales, leads, etc. It’s only through the use of Salesforce that these metrics get influenced.

Close rate, sales booked, and leads generated are functions of your sales efforts, the activity of marketers, R&D, etc. These metrics are also heavily influenced by external sources. Sales might fall because of the economy, leads are not generated because of a poor website, and so on. To get success metrics that focus specifically on the operation of Salesforce we must find indicators that that show how Salesforce is performing. You must then detail how these metrics influence bottom line results.

Here’s a quick list of success metrics, with a brief idea on how they impact bottom line results:

Login rate
Adoption rate is the king of all salesforce measurements, meaning the login rate should be the most closely monitored of all metrics. It should be clear that if people aren’t using the system, it will not impact revenue. While login rates will vary depending on the organization, you should strive for:

  • Daily login for all sales people
  • A steadily increasing by all profiles
  • An increase when any new functionality is introduced

Usage
Moving one step beyond login rates will paint a more complete picture of user adoption. Where ever possible, you should be measuring: (this list is just an example, these measures can get very specific)

  • Record creation and modification
  • Report creation – if users are creating these themselves, you know your doing something right
  • Opportunity modification – when users are making detailed changes to the opportunity, it suggests the opportunity logic is being used to manage sales
  • Tool usage – if new tools are introduced, determine ways to measure if / how these tools are being used

The ability to measure KPI’s
While this may not sound like a success metric, the ability to measure KPI’s can be the most important result of Salesforce usage. If your organization is unable to determine metrics like close rate, lead source, forecasts, etc., you have something to strive for. The ability to measure these items are binary, you can or can’t do it. List the KPI’s your organization wants to measure, and ensure the Salesforce is used and configured to achieve these these measurements. When you can measure, you can manage things like:

  • Which deals close at a higher rate
  • Which deals are more profitable
  • Which leads convert at a higher rate
  • Who your most profitable customers are

When armed with this information, your company can begin to optimize it’s efforts. Direct ROI is achieved through this optimization. For example:

  • Your company can allocate more sales resources to your most profitable customers
  • Stop spending money on unprofitable lead sources
  • Determine which sales people are the most effective

User feedback
This one is simple, if users don’t like the system, it generally won’t yield ROI. Users should see Salesforce as a tool that helps them do their job, not a painful place to enter orders. If Salesforce is to become a critical business tool, find some time to talk to users and collect feedback. You should also segment users based on their login rates, and find out why users aren’t logging in, and why power users love the system.

Salesforce data quality
This metric is related to the ability to track KPI’s, because without good data, KPI’s can’t be trusted. At the very least, data should be stored so KPI’s can be generated without the need for ad-hawk reporting. Determine what information is critical to your origination, and measure if records are collecting this information. Records can be scored by their completeness, and users can be identified by their tendency to create good and poor quality records.

Efficiency
Salesforce success should not only be measured on it’s influence on sales. Salesforce also has the ability to automate person hours out of existence. If the reasons for implementing Salesforce is to improve process and workflow, you will need to create benchmarks for the time it took to complete an activity before and after Salesforce. This of course needs to include the added expense and administrative time Salesforce now requires. These hours saved can be reported on as monetary improvements to the business.

Depending on your objective, you can measurably improve things like:

  • Time to quote
  • Time to bill
  • Time to deliver the product or service
  • Time to create end of month reports
Filed Under: Salesforce Tagged With: , ,

The Salesforce nonprofit starter pack, explained

November 22, 2010 By 2 Comments

I have now worked with, and spoken to a number of medium to large charities and not-for-profits, and each share a common challenge: not understanding what the “nonprofit edition” of Salesforce is. While lots has been written on the existence of Salesforce.com’s donation program and it’s features, there is still confusion as to how this edition is different from Salesforce.com’s other products.

This challenge is largely do to the way salesforce.com brands their products. Salesforce.com has decided to make all the products they offer seem like unique, packaged applications. This approach has extended to the nonprofit edition of Salesforce, which has created this confusion.

Salesforce Enterprise Edition, and the not-for-profit edition are the same thing
I want to be very clear, the nonprofit edition is an enterprise edition license of Salesforce. Every feature – including the Force.com developer tools – that enterprise edition comes with, are included with the NFP edition. The only thing that makes the NFP edition unique, is a group of tools which have been pre-installed through ‘managed packages’. These packages are known as the nonprofit starter pack.

What are these tools?
A managed package is a set of functionality that is installed into a Salesforce account. This functionality has attempted to make the standard Salesforce environment more alligned with the standard requirements of a NFP. Here’s a very quick overview of each feature.

Contacts and organizations:

  • Renames the “account” object to “organizations”
  • Allows individual contacts to be created without the need to associate them to an account (which is required in the standard Salesforce edition)
  • Rolls-up donations to the contact – the standard Salesforce edition only rolls up transactions to the account
  • Allows multiple phone numbers and email addresses – However, I’m a fan of this tool

Recurring donations:

  • This is a light weight tool which automatically crease ‘donations’ that occur on a regular interval

Relationships:

  • Allows contacts to be associated with other contacts
  • Adds fields for social media addresses

Affiliations:

  • Allows contacts to be associated to multiple organizations
  • Tracks when a contact is associated to a new organization - for example when they change jobs

Householding:

  • Allows contacts to be related to each other through a household record

There is now a 2.0 release of the nonprofit starter pack, which should be available shortly. You can get the detailed on each of the NFP starter pack features here. The Salesforce foundation has a good overview of all the features here.

It’s called a “starter pack” for a reason
While these features may sound great, in practice each of the above features are limited. The light weight nature of these tools are good to get started with, but even simple requirements may not be supported. So don’t get completely hung up on the idea that these tools are a silver bullet for your use of Salesforce.

When you out grow these features
The challenge with working with the nonprofit starter pack is that the behavour can’t be modified (technically this is due to the type of package). This often causes us to uninstall the feature set, and build to the clients specific requirements.

The good news is that the nonprofit edition is enterprise edition, meaning we can make just about anything work – and easily re-create the nonprofit starter pack features. The point that I’m making is rather than bending to the above features, you should divorce yourself from them, and look at your true requirements.

Filed Under: Salesforce Tagged With: , , ,

Administrative pre-work for any major Salesforce development project

November 15, 2010 By 9 Comments

As a Salesforce consultant I like to add value to an orginization through their use of Salesforce, but that quickly gets complicated when my first recommendation is to cleanup Salesforce, before any significant feature development can take place.

It’s always a challenge when the client wants new features to drive efficiencies and increase adoption, but they’re stuck in a situation where they need to crawl out of debt first. My recommendations to clean up Salesforce – and keep it clean – are the following:

1. De-duplicate Salesforce records
Dupes not only make finding records hard, it causes users to lose trust in the system, killing adoption. When users don’t trust the system, it’s pointless to enhance your Salesforce instance. With a little time, this can be easily fixed using DemandTools. While this will take time and money for the DemandTools licence, it’s well worth the investment.

2. Purge fields that are no longer used
Your text field labeled “2008 promo campaign” is no longer valuable (and shouldn’t have been there in the first place). These fields clutter page layouts and reports, and will ultimately lead to bad data. If there is data in these fields that you need to keep, find other fields to push this data into, and remove or delete the field.

3. Delete or deactivate unused workflow rules
If you have a great deal of active workflow rules, look these over to be sure they are still doing something of value. Before additional functionality can be added, we must be sure that we don’t run into workflow rule excepts creating complex errors that need to be debugged.

4. Clean up or simplify your security and sharing model
 Over time we create profiles, add field level security, tweak our security sharing rules. While these are necessary, it becomes very easy to trip over complex security models. Again this can create complex debugging activities if your security model is too complex.

5. Verify if validation rules are still required
 While validation rules are implemented for good reasons, over time the data that they protect may or may not be useful anymore. Audit these rules to ensure they add value, otherwise you will trip over these rules as you introduce enhancements or new data sources.

6. Implement some of your high demand nice to haves
 While it might seem strange to include the introduction of new features in a list like this one, delivering those features which are low(er) effort but deliver value quickly, is a great way to win support from users and other stakeholders. I just hope you’ve been keeping a list of these, because asking users now, will lead to chaotic feature creep.

7. Stop adding fields so Marketing / Sales / or any other department can track and segment records
 I’ve seen standard objects with 20-30+ fields that no longer serve any purpose. Many of them were originally created because of some obscure request by sales managers or marketing people to track a campaign. These fields confuse sales people, and cause them to miss critical fields. In the long run, these excess fields lead to poorer data not better.

When faced with requests for these fields going forward, think of other ways that allows the user to track what they want. Often the association to a campaign, a creation date, or setting field history is enough.

8. Remover or archive unused reports
 Let’s face it, end users just want to get to the data they care about, and get out. Take an inventory of the reports that are actually used, and start to remove those that are not. These unnecessary reports make report lists very long, and clutter the UI. At the very least move them to some kind of archived folder.

Filed Under: Salesforce Tagged With:
« Older Posts