Module best practices

Modules do not typically contain case types as something for reuse, because case types can be difficult to reuse without extending, which makes them not updatable. Additionally, case types are usually very specific to an individual end-to-end workflow.

Most rules within a module should be final, meaning that they can't be changed or overridden, and any configurable behavior should be implemented using configuration sets.

Some of the additional characteristics that guide Module creation are that modules should:

• contain little more than connectors and data pages, as well as classes and properties inheriting from Int- and Data- 
• be lightweight, not containing many rules or rulesets 
• be wrapped around a single data object (for example, a card, address, or customer) or single feature set (for example, correspondence generation, task creation, and so on) 
• be fully encapsulated – meaning that they have no dependencies on anything but the most reusable of assets from the application or enterprise 
• accelerate low-code adoption by placing reusable processes (automations) in the most common classes (for example, Work-) to allow maximum portability. 

Achieving the right granularity of Modules is critical to their wide-spread reuse. When evaluating a potential module, consider it in terms of the following usability criteria:

• Is it transparent?
• Can it be encapsulated?
• Is it largely self-documenting?
• Is it easy to consume?
• Can it be parameterized?
• Does it provide appropriate flexibility?
• Is it App Studio friendly?

The following list shows some common examples of highly reusable Modules and their purposes:

• Customer – to find customers; to retrieve data about a single customer, and perform customer updates
• Employee – to find employees and retrieve data about a single employee
• Messaging – to send messages within an organization; select pre-written messages to use as message text, and update message content before sending
• Contact-Method – to enter an address, phone, email, and other details.

Finally, the following interactive figure shows an example of modular architecture. The building blocks start at a granular layer, at the bottom. As the blocks move up through the layers, they take on more functionality in a modular way, allowing them to be reused across several applications (at the top of the diagram).

Click on the hotspots to learn more.