Configuration and migration guide

​

Applications

​

Consolidated resource management

• Change: All resources that were previously managed individually within processes are now grouped within Applications. This includes content management elements, integrations, themes, task configurations, and permissions.
• Impact: Resources like enumerations, substitution tags, and generic parameters are now managed within Applications, allowing centralized configuration and version control.
• Migration: All process-related resources will be migrated automatically into a default application, ensuring continuity of functionality in the new framework. After migration, you should verify that all critical resources are correctly configured within this default application.

​

Enhanced version control and dependency management

• Impact: Applications support dependency management through Libraries and enforce version-controlled resources. Setting up an application now requires careful dependency management and versioning to prevent unintended updates.
• Benefit: Allows for modular, reusable resources and stable deployments across applications, reducing resource duplication and enhancing project compatibility.

​

Migration checklist

1. Verify Process Migration: Confirm that all existing process definitions have been correctly migrated into the default application.
2. Set Configuration Parameter Overrides: Post-deployment, adjust environment-specific Configuration Parameters in the default application.
3. Update Task Views: Replace the global “All Tasks” feature with application-specific Views in each application.
4. Transfer Processes and Dependencies Manually: If moving a process from the default application to another application, manually transfer associated resources and re-check dependencies.

​

Generic parameters migration

• Overview: In version 4.5.0, global generic parameters (from versions prior to 4.5.0) have been migrated to application-level as Configuration Parameters, consolidating parameter management within specific applications for improved organization and control.

• Migration: All generic parameters will be automatically migrated to Configuration Parameters section under a default application.
• Business Rules Unaffected: There is no impact on existing business rules; they will continue to function as before without requiring updates.
• Process Export Considerations: If you export a process from one application to another, ensure that you also transfer the associated configuration parameters. This step is crucial to maintain process functionality and consistency across applications.
• Important Note: Only values of generic parameters associated with the specific environment, or where env = null (displayed as “all” in the interface in versions prior to 4.5.0), will be migrated. You must ensure that you have correctly set the values for generic parameters, paying attention to environment values (which are case-sensitive), and export these generic parameters before migration to avoid any potential data loss.

• Post-Deployment Step: After the first deployment to an upper environment, you will need to create configuration parameter overrides with the specific values required for that environment. This ensures that all environment-specific configurations are accurately maintained and applied across different deployment stages.

​

Task management

• “All Tasks” as a View: The global “All Tasks” feature is no longer standalone and will now function as a View in an application.

​

General

1. Merge All Feature Branches: Ensure all feature branches for processes are merged into the latest version on the main branch.
2. Remove Unnecessary Resources: Delete any test processes or resources that are no longer needed.
3. Export Generic Parameters: Export generic parameters as a backup to ensure they migrate accurately to application-specific Configuration Parameters.

​

Migration steps

• Process Definitions: Only the last committed process version on the main branch will migrate. If no committed version exists, the latest WIP version will be used.
• Enumerations, Substitution Tags, and Task Manager: These resources will be migrated to the default application.
• Generic Parameters: Migrated as Configuration Parameters within the default application, covering only values where env = null or that match the platform’s environment setting.
• Languages: Language settings (available languages and default) will be moved to application settings. Languages remain globally available.

​

Resources excluded from migration

• Themes
• Fonts
• Global Media Library (for media used in themes)
• Source Systems
• Notifications and Document Templates
• Out of Office (Task Manager)
• Integration Management (not included in v4.5)
• Content Models (deprecated)

​

Datepicker Migration

​

Key changes

1. Introduction of Date Types:
   • Standard Date: Stores and displays date values in ISO 8601 format, respecting the application’s locale and timezone settings.
   • Legacy Date: Retains previous formatting to ensure compatibility with existing business rules and processes.
2. Properties Updates:
   • The Datepicker now supports dependent properties such as minDate, maxDate, and defaultValue. These properties:
     • Follow the formatting rules of the selected date type (Standard or Legacy).
     • Ensure that dynamic date values pulled from the Data Model are displayed correctly.
3. Backward Compatibility:
   • Existing Processes: All migrated processes with legacy Datepicker components will default to Legacy Date type. This preserves the original formatting and ensures no disruption in business rules or workflows.
   • New Processes: Newly created processes will default to Standard Date type, saving values in ISO 8601 format.

​

Migration process

1. Legacy Datepickers:
   • Automatically flagged during migration.
   • Continue to work with existing business rules.
   • Require manual review for future updates to transition to the Standard Date format.
2. Business Rules Updates:
   • Legacy Datepickers may require manual adjustments if associated business rules reference hardcoded date formats.
   • Ensure that any dynamic dates used in business rules are compatible with the ISO 8601 standard.
3. Standard Datepickers:
   • All new Datepicker components save date values directly in ISO 8601 format.
   • Fully compatible with updated Data Model attributes, allowing seamless integration with external systems, adaptors, and reporting plugins.

​

Considerations

• Default Values:
  • For Standard Datepickers, the defaultValue must be in ISO 8601 format.
  • Dynamic defaults can also be set using Data Model attributes or process data.
• Data Model Integration:
  • All external and internal date attributes, including those used by adaptors or business rules, must be explicitly defined in the Data Model.
• UI Designer Overrides:
  • Overrides can be applied to display dates differently for specific UI elements, ensuring flexibility for localized formatting.

​

Recommendations for transition

• Existing Processes:
  • Leave Datepicker components in Legacy mode unless business rules and workflows are updated to support ISO 8601.
• New Processes:
  • Use Standard Date to ensure future compatibility and alignment with ISO 8601 formatting.
• Documentation:
  • Review and update all timer expressions, adaptors, and external data feeds to use ISO 8601 format for consistency.

​

Post-migration recommendations

1. Create Branches within the Default Application: Organize and streamline resources by creating branches. This enables a lightweight build focused on production.
2. Split the Default Application into Smaller Applications: Use the import/export feature to separate the default application into individual applications by use case.
   • Note: When importing processes into a new application, resource references may need to be manually reconfigured.