Nested conditions along the lines of ((foo or bar) and baz) are hard to comprehend, and I understand that you want to avoid them. Indeed, you can avoid the logical operators and, or and not if you allow conditionals to be nested:
if (foo and bar) then actionis equivalent toif (foo) then if (bar) then actionif (foo or bar) then actionis equivalent toif (foo) then actionotherwise if (bar) then actionif (not foo) then actionis equivalent toif (foo) then nothingotherwise actionif ((foo or bar) and baz) then actionis equivalent toif (foo) then if (baz) then actionotherwise if (bar) then if (baz) then actionor
if (baz) then if (foo) then action otherwise if (bar) then action
This isn't exactly easy to understand either, and requires a lot of repetition.
It might be much simpler to allow one if … then … to have multiple conditions that can be combined via any of, all of and none of quantifiers (these correspond to the mathematical quantifiers ∃ there exists, ∀ for all, and ∄ there does not exist). This is easy to introduce into a form-based interface, and drastically increases power and usability of your rules. However, they are not quite as powerful as arbitrarily-nested conditions. This can be resolved by introducing user-defined variables or virtual fields. With variables, sub-conditions can be combined, named, and re-used.
Using these two improvements, a conditional if ((foo or bar) and baz) then action might become
yes/no field foo-or-baris any offooorbarif all of foo-or-barandbazthenaction
where foo, bar, baz are arbitrary atomic conditions. This achieves the same expressivity as nested condition expressions, without requiring users to repeat their conditions and actions.