Who is this article for?

Module developers and Users configuring and testing new projects or changes.

Area access is required.

Fields are used to collect individual pieces of data within a module. The number of available fields, per module, is limited by type. Fields can be one of many types. The most common types of fields in a module are:

• Character Small (up to 250 characters)
• Character Large (up to 4,000 characters by default, can overflow to 100,000)
• Checkbox
• Date
• Numeric
• Picklist (typically a list of less than 20 options)
• Reference (refers to data from another module, which is typically managed by the customer)
• Time

Field Behaviors

Behaviors affect how a field, and other aspects of a module, behave based on one or more rules. Multiple behaviors can be applied to a field at once.

Example requirement to apply a behavior to a field
Set “significance level" (the field) to “non-modifiable" (the behavior) when the current workflow step is beyond “screen" (the rule).

Note that implied in this behavior and rule combination is that if the workflow step is at the screen or prior workflow steps the field is modifiable (which is the default behavior).

When a new field is added to a module its default behaviors are as follows:

• Visible to all users who have access to the object, in all workflow steps
• Modifiable by all users who have access to the object, in all workflow steps
• Not required
• The prompt is the name of the field, and the prompt is neither bold nor italicized
• Location in the default region of the screen layout

These default behaviors can be changed by applying one or more of the following behaviors:

• Invisible: Hides a field (e.g., A calculated field only required for reporting.)
• Non-modifiable: Restricts the modification of a field (e.g., You want the user to see the field but not be able to modify it.)
• Required: Makes a field required and adds a red asterisk to the field prompt (The user cannot submit the object without populating the field)
• Bold: Make the field prompt bold
• Italics: Make the field prompt italicized
• Region: Section of the screen layout where a field should be displayed
• Prompt: The name displayed on the screen for the field, which could be different than the field name in Module Builder
• Empty value text: Grey text that will appear in a field when that field value is null, designed to help the user
• Refresh (recalc): Like the Refresh on Change calculation mentioned below but can be controlled via a rule

Where is the “Visible" behavior?
Module behaviors do not exist for the opposite behavior. For example, "Visible" is not an available behavior. To make a currently invisible field visible, it is necessary to return the field to the default setting of visible by removing or modifying the existing rule that is making the field invisible.

WARNING: Avoid conflicting behaviors
While it is common to apply multiple behaviors to a field, care must be taken not to create situations that make the module unusable. For example: setting a field to be required while also making it invisible.

Field Properties

In addition to Behaviors, fields can also have Properties applied to them. Properties are not conditional, which means they aren’t dependent on rules. Properties are either defined for a field, or they are not. Each of these properties need to be considered for every field added to a module. Common properties include:

• Help Text (Hover help): Text that will display when a user hovers over the question mark next to the field prompt
• Calculation Recalc: If checked, non-null values will be updated when calculations run and if not checked, non-null values will not update when calculations run
• Common Fields: Fields that can be used to search across multiple modules
• Display Order: The order in which a field needs to be displayed in relationship to other fields
• Display Region (Miramar): The region of the screen layout or workflow step where a field should be displayed in the Miramar standard workflow layout
• Print region: Fields that need to be included in the print book/report
• Refresh on Change: Run calculations and refresh the browser when the value for this field changes
• Search Filter: Fields that can be added as a search filter (Field types of Character Small, Character Large, Time, and Numeric are not enabled as search filters by default)
• Search Filter Default: Fields that are added as a default filter list when searching the module
• Search Grids/Reports: Fields that are available to be added to a grid report
• Search Grides/Reports Default: Fields that are automatically added to a grid report
• Track history: Revision remarks of the fields that changed after a save (By default, this property is enabled but can be disabled for fields where sensitive data should not be displayed in an object’s history, or where the history provides no value and will never be needed)

Reference Field Search Filters

When a user is required to select a value for a reference field, they are, by default, presented with all objects associated with the reference module. Reference fields have the capability to display dropdown lists upon the user's interaction with the field.

This approach is not always optimal, as users may be required to scroll through numerous values that are unlikely to be selected. To locate a specific value within an extensive list, users may click the edit icon in the field to access the menu options for that field. 

The field menu options provide users with a variety of functionalities designed to enhance their experience and streamline their workflow. Users can easily search for and locate specific items within the field. Additionally, if permissions allow, users have the ability to create new items directly from the menu, facilitating efficient data entry and management. The menu also includes an option to clear the field, which helps users reset their selections or inputs without hassle. And, when additional details are available, users can view more comprehensive information about a particular item, enabling them to make informed decisions or gain deeper insights.

A radio group enables users to select a single option from a set of mutually exclusive choices. This functionality is particularly beneficial when it is necessary for the user to choose only one option from a list. The radio group prevents the selection of multiple options, thereby avoiding conflicts and ensuring that the chosen value is transmitted to the server for processing.

Conversely, a checkbox group shares a group name and a validation rule, facilitating structured, rule-based selections, such as "select any three values" or managing parent data alongside all associated child-level data. When this configuration is utilized, data exports must list each checkbox with a distinct field name.

To minimize the number of objects displayed to the user, the results can be filtered according to the value of an additional field. For instance, when searching for a specific Building within a Location module, it is advisable to apply a filter on the Type field to return only “Building” objects, thereby excluding all Plants, Areas, and Rooms.

Common reference filter options can be configured to display:

• Only enabled objects, filtering out disabled objects
• Assets based on a parent building or location
• Users based on active qualifications
• Departments based on the logged-on user's own department

Field Levels

A module can also include two types of field levels:

• Header-level: Fields where there can only be one value at a time per object.
  • Examples are Title, Date Created, and Current Task
  • While the value of the field Current Task may change over the life of the object, only one task is current at a time
• Child-Level: Fields where there can be many values, per object
  • Examples are Trend Codes, Actions, and Comments
  • Each child level can be thought of as a table where one or many rows can be created, and which may have columns representing different fields per row

The child-level data is often displayed in the form of radio buttons, picklists, grids, tags, or cards.