Clear instructions and documentation are also very helpful. This includes not only instructions in your configuration documents, but also clear error messages that indicate what actions need to be taken if, for example, a lookup fails to find the configuration information it's looking for, and clarity on how the configuration is presented and labeled is lacking. As with any application, the better the user documentation, the more likely the users are to be able to figure it out without having to call the developers. And yes, this takes a little extra time when you're planning and coding, but I assure you, it'll pay off in the long run.

Application control
Are different groups of users responsible for different parts of the application? Make it easy for your users to find the pieces they're concerned with. This will keep them, and the other groups whose information they might change inadvertently, much happier. For example, we have a requisition application that our employees use to make IT and Facilities requests. The basic request form has sections for Furniture, Telecom, and IT Equipment, among other things. The configuration documents that we built are divided up along those lines as well, so that a person from Telecom who wants to make changes in the choices available under that section only has to deal with their information.

It also helps to make the configuration controls easy to get to for the right people, and well hidden for the others. I try to keep this consistent across all of the applications in our organization through the use of standard components tied into a master template and the use of standard role names and definitions.

User knowledge
How strong are your users, and/or how much turnover do you have among user administrators? In some organizations with well-trained professionals and stable organization charts this may not be much of a concern, however, in many organizations it is. The key here is documentation. If you have access to them, this is a good place to get the help of skilled technical writers.

What you're building when you make your application customizable is a great way for a user to mess up your application, as well as a way to keep it living longer with less work from you. You need clear and concise instructions for making changes, as well as clear warnings for how this might mess things up. Even if you're in a stable organization, it never hurts to document clearly (and not just in the user interface!).

Buy-in
Last, but far from least, how do you get your users to actually use what you've built? This can be the toughy. By the exercise of great patience, and by pointing out that they can make the change whenever they feel it needs to be made instead of waiting days (sometimes) for a developer to get around to it, we've turned many users into great believers. Others, well… Like I said, we've learned how to exercise great patience. Most managers should see the advantage of the slight increase in development time, if you can sell them on the increased flexibility and life of the applications, the increase in control in their hands, and, best of all, the decrease in developer time for maintenance in the long run. Which means they'll have more money for other projects.