If this is to cut down on if-else code then I'd say it depends on how many if-elses you're saving. More often I see people take this approach to let end users

If this is to cut down on if-else code then I'd say it depends on how many if-elses you're saving. More often I see people take this approach to let end users compose rules for various actions. But this kind of thing tends to be what I call a "Turing complete" feature, where people are always writing rules that go beyond what your model can express. ("If there are two of these, and one is not older than this, and their mean is greater than the most recent of these, and the current time is before 8 a.m. in the time zone of the user who owns this user's account . . .") In that case, if your users are sophisticated enough (e.g. internal users in a "services" division of your company), you might want to consider going with embedded Javascript instead. You can expose a few objects/functions from your application and let people write JS using them. Then you run their JS and see if it evaluates to true. I've used this in a Ruby context before with the gem therubyracer. This is nice because your app gets a full-featured scripting language for free. You don't have to design the language or write an interpreter. Javascript is designed to be very secure. It can't do IO or run shell commands. And it's probably the most widely-understood programming language out there, so there's a low learning curve. Challenges are that your users have to understand a programming language, and you'll probably want to take steps to validate the Javascript they're writing and to surface decent error messages when problems happen. Also therubyracer can use a lot of memory, which may or may not be a concern depending. Another challenge is that the JS will be opaque to an outside computer system. It's hard to break it down and express what it's all about. For instance you couldn't run a query to find all actions that require condition foo. Good luck!