Business rules in KRMS are placed into ordered sets called "agendas". The order of the rules in an agenda determines the sequencing, which rule gets evaluated first, second and so on, and the agenda also enables you to include conditional branching logic.

In turn, agendas are placed into "contexts". You can set up contexts ro represent any categories that are relevant within your institution, for example they could be document types or business processes or any other categories. In some university environments, the following might be relevant contexts: Awards, Proposals, IRB reviews, Course co-requisites, Course pre-requisites, Student plan evaluations, and so on.

Each defined context contains its own agendas, and each agenda contains its own rules. Rules aren't shared across agendas (though you can copy/paste, they become unique rule instances), and agendas aren't shared across contexts. There is no context hierarchy, that is, agendas and rules can't be inherited across contexts within any sort of hierarchy.

See below for a view of the Agenda Editor in KRMS.

And see below for an example of how attributes can be progressively rendered in KRMS. In this example, the type of "CampusAgendaType" requires some additional attributes, that are not required by all types. These are shown to the end user only when required. This is an example of KRAD's progressive disclosure capability:

Each defined agenda in KRMS contains its own rules. Rules aren't shared across agendas (though you can copy/paste, they become unique rule instances), and agendas aren't shared across contexts. There is no context hierarchy, that is, agendas and rules can't be inherited across contexts within any sort of hierarchy.

See below for a view of the Rules Editor in KRMS.