This article is part of a series on common questions we discuss about building rule engine focused applications. 

Understanding a users skill level and technical competency is critical in designing a meaningful rule authoring experience. As you explore rule engines in general you’ll find a variety of rule editors that vary on a spectrum from “capable but complex” to “easy, but constrained”.  Instead of making the capable versus constrained decision for our customers and partners we decided to provide configurable tooling that let’s you decide the scope of a given users rule authoring experience.

For example, there may be different users or groups of users who are responsible for updating the rules for a given region or a given product area. In these cases you want to limit the complexity of the authoring environment by restricting access to only these regions or products – and even further limit the objects and verbs these users have to create rules with. These users may not have access to anything but a few rules or rule sets and they would not be able to create forms or create dashboards – they would login and only have access to the rules they are responsible for maintaining.

You can add additional constraint by separating the duties of the rule maintenance process. This is especially helpful for junior level users who you may want to edit the rules – but who you may not trust to appropriately test these rules or deploy them into a production environment. Using Decisions Repository you could have users who are responsible for different phases of the rule development lifecycle including: creation, editing, testing, and deployment.