Summary: This document provides comprehensive information about field types and configuration options available when creating task templates in Onahiri Platform. Understanding field types and their capabilities is essential for creating effective templates.

Field Basics

Field Structure

Each field in a template consists of these components:

• Field Name: The internal name used in the system (API name)
• Display Label: The user-visible name shown in forms and views
• Field Type: The kind of data the field will contain
• Required Flag: Whether the field must be completed
• Type-specific Properties: Additional settings based on field type

Field Naming Best Practices

For optimal field configuration:

1. Field Names:
   • Use camelCase format (e.g., “projectManager”)
   • Avoid spaces or special characters
   • Keep names concise but descriptive
   • Use consistent naming conventions
2. Display Labels:
   • Use proper capitalization (e.g., “Project Manager”)
   • Keep labels clear and concise
   • Use consistent terminology
   • Consider adding help text for complex fields

Field Types

The system supports various field types, each with specific purposes and properties:

Text Input

Purpose: Collect short text entries such as names, titles, or brief descriptions.

Properties:

• Standard single-line text field
• No formatting options
• Ideal for short answers

Best Practices:

• Use for small discrete pieces of information
• Avoid for longer content (use Text Area instead)
• Consider maximum length constraints for validation

Text Area

Purpose: Collect longer text content such as descriptions, notes, or comments.

Properties:

• Multi-line text capability
• Scrollable when content exceeds visible area
• No rich text formatting

Best Practices:

• Use for descriptions, instructions, or detailed notes
• Consider minimum/maximum length requirements
• Reserve for content that may require multiple sentences or paragraphs

Number

Purpose: Collect numeric values such as quantities, ratings, or measurements.

Properties:

• Accepts only numeric input
• Can optionally set minimum/maximum values
• Supports decimal places

Best Practices:

• Use for any quantitative data
• Consider adding units in the field label if applicable
• Set appropriate min/max values to prevent errors

Currency

Purpose: Collect monetary values.

Properties:

• Numeric field optimized for currency
• Configurable currency symbol (defaults to $)
• Automatically formats with appropriate decimal places

Best Practices:

• Use for budget amounts, costs, or other financial values
• Ensure the correct currency symbol is configured
• Consider adding validation for reasonable value ranges

Date

Purpose: Collect calendar dates such as deadlines, start dates, or event dates.

Properties:

• Includes date picker calendar interface
• Standardized date format
• Prevents invalid dates

Best Practices:

• Use for any time-sensitive information
• Consider adding validation for reasonable date ranges
• Avoid using for time-specific data (time is not included)

Single Select

Purpose: Allow selection from a predefined list of options.

Properties:

• Dropdown menu of options
• Only one option can be selected
• Options must be configured during template creation

Best Practices:

• Use when there are mutually exclusive choices
• Limit to a reasonable number of options (ideally fewer than 10)
• Arrange options in a logical order (alphabetical, priority, etc.)
• Ensure option labels are clear and distinct

Multiple Users

Purpose: Associate multiple people with a task in a specific capacity.

Properties:

• User picker interface with search capability
• Can select multiple individuals
• Displays user avatars and names

Best Practices:

• Use for stakeholders, team members, or reviewers
• Consider combining with role assignments
• Use descriptive labels that indicate the users’ relationship to the task

Multiple Organization Units

Purpose: Associate multiple departments or teams with a task.

Properties:

• Organization unit picker with search capability
• Can select multiple units
• Displays unit names and icons

Best Practices:

• Use for cross-functional tasks
• Consider the hierarchy of organization units
• Label clearly to indicate why units are being associated

Yes/No (Boolean)

Purpose: Collect binary choices.

Properties:

• Simple toggle or checkbox interface
• Only two possible values (true/false)
• Can set default value

Best Practices:

• Use for clear binary decisions
• Phrase the label as a question when possible
• Consider the default state carefully

Checklist

Purpose: Create multiple completion items within a single field.

Properties:

• Configurable list of items with checkboxes
• Can set default items during template creation
• Users can add/remove items in tasks
• Progress tracked as percentage complete

Best Practices:

• Use for steps, requirements, or verification items
• Keep individual checklist items concise
• Order items logically (sequence, priority, etc.)
• Consider pre-populating with common items

Field Configuration Details

Required Fields

Marking a field as required:

• Forces users to complete the field before saving
• Displays a visual indicator (usually an asterisk)
• Validates presence upon submission

Consider carefully which fields should be required:

• Too many required fields can create friction
• Too few may result in incomplete information
• Required fields should be genuinely necessary for the task

Field Descriptions

While not visible in the template configuration interface, field descriptions can be added in the task form:

• Provide additional context and guidance
• Explain the purpose or expected format of the field
• Help users understand why the information is needed

Field Order

The order in which fields appear in templates:

• Is determined by the sequence of creation
• Can be changed by removing and re-adding fields
• Should follow a logical progression

Best practices for field order:

1. Group related fields together
2. Place most important fields at the top
3. Follow a natural information flow
4. Consider the task creation workflow

Advanced Field Usage

Conditional Fields

While the template system doesn’t directly support conditional fields (showing/hiding based on other values), you can:

• Use clear field labels to indicate when certain fields should be completed
• Create separate templates for significantly different workflows
• Provide instructions in the template description

Field Dependencies

When fields have logical dependencies:

• Order them appropriately in the template
• Use clear labeling to indicate relationships
• Consider using a checklist field for related items

Field Best Practices

For the most effective form design:

1. Minimize Field Count: Only collect truly necessary information
2. Group Logically: Keep related fields together
3. Start Simple: Add complexity only as needed
4. Be Consistent: Use similar field types for similar data across templates
5. Consider Reporting: Think about how field data might be used in reports or filters