Let's say that you have

• Application: MyTaskManager
  • Ruleset: MyTask
  • Ruleset: ItemManagement
• Application: MyBugManager
  • Ruleset: MyBug
  • Ruleset: ItemManagement
• Application: MyWorkManager
  • Ruleset: MyBug
  • Ruleset: MyTask
  • Ruleset: ItemManagement

Some users just perform tasks, so they get MyTaskManager. Some users just fix bugs, and they get MyBugManager. Some users do both, they get MyWorkManager.

If you do your application development in MyWorkManager, the app with all three ruleset, you will eventually make the mistake of referencing a rule in MyBug Ruleset from MyTask Ruleset or via versa. If you do this, users who are running MyTaskManager or MyBugManager will not have access to all the rules and exceptions will occur. For example, you might create a local action in MyTask Ruleset that creates a new bug and calls a rule in MyBug Ruleset. This is fine if you have MyWorkManager application, but not okay if you have either of the others.

In the case outlined above, you may be overcomplicating things needlessly by having so many rulesets. Personally, I would recommend something like:

• Application: MyWorkManager
  • Ruleset: ItemManagement

You would then control 1) what users see and 2) what they can process using privileges.

If you do need to have a reuse ruleset, just give it its own application:

• Application: MyClaimManager
  • Ruleset: MyClaim
• Application: MyTimeSheetApp
  • Ruleset: MyTimeSheet
• Application: MyConnect
  • Ruleset: MyConnectors

In this example, both MyClaimManager and MyTimeSheetApp are both built on MyConnect because they might use the same connectors to call common services. Using built on apps in this case will prevent developers from building rules in MyConnect from calling Claim or Time rules.

In conclusion, you should use built-on applications to facilitate rule reuse. Do not use different combinations of rulesets to prevent users from having access to rules.