When to say "No."

Okay, let's be honest. Sometimes, as developers, we have to say "no." Sometimes the case for this is clear. Something like the following: Business Process Owner: We need an application that will do your thinking for you! We can call it the AwesomeApp!! Developer: No. Other times, it's less clear. Say, when you're developing a new business application, and one of the stakeholders wants to change something fairly trivial because it would be easier for them "right now." For instance, take a situation at my job. We have a database to store records relating to medical insurance eligiblity requests. One table holds the actual subscriber (insured) information. Each subscriber gets two records: one for the request, and one for the response. The way the process is designed, there is some information that goes out on the request which is stored with the request. Some of that information can come back differently on the response- this information is housed in the response record. Some of that data cannot (according to industry standards) be changed, so we decided not to store it on the response record. Since the data structures are sufficiently convoluted to require multiple joins to get any useful data anyway, we decided one additional join wouldn't hurt anybody. Also that storing redundant data is kind of silly. One of the BPEs wants that duplicate data in the response record so that a "basic 'What happened to account so-and-so" query won't require joins. Normally, I'd say "Okay" and make the change. In this instance though (again, due to the convoluted nature of the data we send and receive) a received record without it's sent counterpart (and, for that matter, related records in other tables) has absolutely no context and would be worthless even for those "basic" querries. So, I said "no." I will continue to say "no" until over-ruled. What about you, readers? Am I way off base? What are your "Just Say No" stories?