There are many different ways we can say “No.” It doesn’t have to be negative and it doesn’t have to cause bad service to your internal stakeholders.

No: the request isn’t the best solution

Users can get very insistent that a project is completed in a specific way. I’m sure everyone’s had the situation where the requestor insists their project MUST BE completed in a specific manner, even when we know that their request isn’t the best solution. I once had someone ask for a checkbox that MUST be required.

In these situations it’s paramount to know what the actual NEEDS are. What are the problems trying to be solved?

This is when you need to say “No. Here is what we will do to support your needs.”

Remember, you are the Salesforce expert – not the people requesting items. It’s up to you to know when something should be done, shouldn’t be done and HOW it should be done. For example, after digging with the request for the required checkbox, I discovered what they really needed was a picklist field that had a validation rule to require the field but only one certain sales.

No: To protect the data

I cannot count the number of times I’ve had marketing or some sales rep send me an excel spreadsheet and ask to import into Salesforce. Too often these sheets are questionable. For example, I recently saw one that simply had First Name, Last Name, and Company. No email address. No Phone numbers. These were to be imported for “Leads.” I had to ask the questions

• Is the data complete enough to be useful?
• Is the data accurate/recent enough to be useful?
• Will importing this data cause confusion with end users?
• Has this data been cleaned for duplicates and bad formatting?
• Does this data contain all the information to pass validation rules and other field requirements?

When the answers are “No” to any of these questions, I am obligated to respond to the request with the same answer. Here it’s important to say “No. Here’s what we need to do first.” For example: We need to first get Email and Phone numbers so our Sales people have something to actually act upon.

No: To Protect Future Data

Perhaps you’re in the process plans to release Account Teams in your org. This is going to be important long term, but you’re still a month short of having the process plan complete. A manage requests to add a new User look-up field for “Product Implementation Specialist.” Assuming the process for keeping this field up to date and filled in correctly is just fine there are still two potential problems with this request:

• We may be close to running out of Look up fields (Max of 20 per object) and need that for other purposes
• It’s counter to the process you’re about to release

Implementing this request now, means you’ll be un-doing that request in a month when Account Teams go live. This is when you have to say “No. Starting at this time you’ll be able to track this information here.”

No: Protect System Integrity

This is a broad spectrum reason. It include projects to do integration with other systems, to create a new object, a new field, a new value, or any number of projects. The key point is system integrity. Anything that would make the system slow, ineffective, inaccurate, or even dramatically reduce user friendliness should get a “No.”

To Sum Up

“No” is very important. You don’t actually have to use that word. You can say “Stop. Let’s talk about your requirements and the problem you’re trying solve.” You could also say “I can see how that idea will solve your need. We’re releasing a new functionality that will also address it. What would be problematic if you wait an extra month?” Sometimes, you just have to say “No.”

Saying “No” should not end the discussion. You may say “No” in order to get more information and eventually say “Yes,” or change it to “No, but here’s what we will do.” Sometimes, you simply can’t say “no” because of the business needs that are immediate. For example, perhaps we need to have the “Product Implementation Specialist” right now because we’re in the middle of a major audit and need that visibility right away. Or perhaps that import that only has names and company is going to be use to “start” the data entry for users collecting e-mail and phone at a tradeshow.

You may not know any of this unless you say “No.”