Configuration and migration guide

​

Projects

The Projects feature in FlowX AI v4.6.0 is a new structure that organizes all dependencies and resources required for a project into a single deployable view. This enhancement simplifies configuration, deployment, and maintenance by layering projects on top of processes, offering a centralized workspace that encapsulates everything needed for project execution. Several key configuration changes impact how resources and dependencies are managed, deployed, and maintained. This guide provides a breakdown of the configuration changes, automatic migration processes, and manual steps required to ensure a smooth transition.

---

​

Consolidated resource management

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

​

Enhanced version control and dependency management

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

​

Migration checklist

To ensure a smooth transition, complete the following steps:

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

---

​

Generic parameters migration

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

• Migration: All generic parameters will be automatically migrated to Configuration Parameters section under a default project.
• 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 project to another, ensure that you also transfer the associated configuration parameters. This step is crucial to maintain process functionality and consistency across projects.
• 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.6.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.

---

​

Source systems migration

• Change: Source systems have not been migrated automatically and need to be manually recreated.
• New Location: In v4.6.0, source systems have been moved under Integration Designer.
• Manual Migration Required:
  1. Navigate to Integration Designer.
  2. Recreate each source system manually with the same code as in the original configuration.
  3. Ensure the “Enable enumeration value mapping” checkbox is enabled.
• Impact: Failure to manually migrate source systems may result in broken integrations and missing data mappings.

v4.6.0: < v.4.6.0:

​

Task management

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

v4.6.0: v4.1.x:

---

​

General

Before starting the migration, complete the following steps:

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 project-specific Configuration Parameters.

​

Migration steps

During migration, resources will be transferred into a single default project with one committed version.

• 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 project.
• Generic Parameters: Migrated as Configuration Parameters within the default project, 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 project settings. Languages remain globally available.

​

Resources excluded from migration

Some resources will remain globally available or are deprecated:

• Themes
• Fonts
• Global Media Library (for media used in themes)
• Out of Office (Task Manager)
• Integration Management (will not be available in v4.6.0)

---

​

Datepicker Migration

In version 4.6.0, significant updates have been introduced to the Datepicker component to ensure compatibility with ISO 8601 date formats and enhanced handling of date attributes within the Data Model. This migration affects both newly created and existing processes.

​

Key changes

1. Introduction of Date Types:
   • Standard Date: Stores and displays date values in ISO 8601 format, respecting the project’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.

---

​

Updates to expression evaluation

What Changed:

• A fix was implemented in the web expression evaluator regarding how string values are handled during process value replacement.
• Previously, when evaluating dynamic and computed expressions, string variables required manual insertion of double quotes ("") because the system did not automatically add them.
• With the recent fix, the system now automatically adds the necessary quotes for string replacements.

Impact:

• Existing Expressions: If your current dynamic or computed expressions include manually added quotes around string values, these might now result in redundant quotes or incorrect string formatting.
• Behavioral Shift: The automatic quote addition alters how string values are processed, which might affect outputs if the expressions were structured with the expectation of manual quotes.

Action Required:

1. Review Your Expressions: Check any dynamic and computed expressions in your processes that currently include manual double quotes around string values.
2. Modify as Needed: Remove unnecessary double quotes where the system now handles them automatically to prevent duplicate quoting or formatting issues.

---

​

Export/import enumerations (CSV)

In the transition from version 4.1.x to 4.6.0, the following columns have been removed from the enum CSV export format:

• description.application
• description.draft
• contentValue.childContentDescription.application
• contentValue.childContentDescription.draft
• contentValue.childContentDescription.type

Existing CSV export/import processes should be updated to remove references to these columns to ensure compatibility with the 4.6.0 release.

---

​

Post-migration recommendations

For complex projects with multiple use cases, do not use the default project for ongoing development or production builds. Instead:

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

---