> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Post-deployment configuration

> This section contains the steps in the order we recommend for post-deployment configuration of FlowX.AI.

## Redis cache clearing

<Warning>
  **Cache Clearing**:

  * FlowX.AI 5.0 removes process definition versioning. Cache must be cleared to remove legacy cached classes.
  * When you start the runtime-manager on version 5.x, the library-to-library migration runs automatically. You must clear the cache after this step because a new field is added to the build mongo document, which is required for various operations.
</Warning>

### Endpoint

`POST {{baseUrlAdmin}}/api/internal/cache/clear`

### Body:

```json theme={"system"}
{
    "cacheNames": [
        "flowx:core:cache"
    ]
}
```

<Card title="Clear cache endpoint" href="../../../../5.1/docs/api/clear-cache" icon="link" />

## Authentication & authorization

### Add users to default workspace

**Process**:

1. **User Re-login**: Existing configurators must log into FlowX.AI Designer once to create user references in FlowX.AI database
2. **Workspace Assignment**: Organization admin assigns users to the default workspace to reestablish access to existing assets and resources

<Warning>
  **Access Restoration**: Without workspace assignment, existing users will lose access to previously available resources and projects.
</Warning>

<Info>
  This step ensures business continuity by maintaining user access to existing FlowX.AI assets in the new workspace-based architecture.
</Info>

### Role mapping guide

<Warning>
  FlowX.AI 4.7.x roles stored in Keycloak are not automatically migrated. Manual role assignment is required.
</Warning>

<CardGroup cols={2}>
  <Card title="Legacy Role Mapping" icon="arrow-right">
    **FlowX.AI 4.7.x** → **FlowX.AI 5.0**

    * `FLOWX_ADMIN` → `workspace_admin`
    * `FLOWX_CONFIGURATOR` → `workspace_user` or `project_editor`
    * `FLOWX_UI_DESIGNER` → `theme_editor`
    * `FLOWX_VIEWER` → `project_viewer`
    * Custom Keycloak roles → Manual review required
  </Card>

  <Card title="Migration Considerations" icon="lightbulb">
    **Important Changes**

    * Roles are now workspace-scoped
    * More granular permission structure
    * Database-stored instead of token-based
    * New role hierarchy requires review
  </Card>
</CardGroup>

### Migration process

<Steps>
  <Step title="Inventory Current Roles">
    Document all existing Keycloak roles and their assigned users before migration
  </Step>

  <Step title="Map to New Structure">
    Determine appropriate FlowX.AI 5.0 roles for each user based on their current access needs
  </Step>

  <Step title="Plan Workspace Structure">
    Decide how to organize users into workspaces based on business requirements
  </Step>

  <Step title="Assign New Roles">
    Use the FlowX.AI 5.0 interface to assign appropriate roles to users in their respective workspaces
  </Step>

  <Step title="Validate Access">
    Test user access to ensure proper permissions are granted and restrictions are enforced
  </Step>
</Steps>

### For existing customers

<Steps>
  <Step title="Automatic Default Workspace Creation">
    The Authorization System will automatically:

    * Create default organization and workspace
    * Import the admin user from Keycloak
    * Assign organization admin privileges
    * Set up default roles and groups

    <Note>
      The admin user imported here is the same service account referenced in the migration prerequisites. If you followed the prerequisites page and set up the admin Keycloak user beforehand, the Authorization System will pick it up automatically during this step — no additional action is needed.
    </Note>
  </Step>

  <Step title="data-sync Migration Process">
    The data-sync service will:

    * Migrate existing projects from Application Manager database to CAS database
    * Assign all existing resources to the default workspace
    * Preserve all existing functionality
    * Require temporary write access to CAS database

    **Note**: This is the only exception to the exclusive write access rule.
  </Step>

  <Step title="Process Instance Migration">
    Process instance migration occurs automatically when the platform starts:

    * **Active process instances**: Automatically migrated to the default workspace during platform startup
    * **Inactive process instances**: Require a separate migration script that runs post-migration

    <Warning>
      For clients who need inactive process instances migrated, a migration script will be provided to run post-migration.
    </Warning>
  </Step>
</Steps>

***

## Header migration: Fx-BuildId to Fx-Build-App-Version-Id

### Background

The header `Fx-BuildId` has been renamed to `Fx-Build-App-Version-Id` to accurately reflect that it contains an application version identifier, not a build identifier.

### Migration strategy

During the transition period, both headers are supported:

* **New messages**: Include `Fx-Build-App-Version-Id` with the application version ID
* **Legacy support**: `Fx-BuildId` is still accepted for backward compatibility
* **Priority**: FlowX.AI platform reads `Fx-Build-App-Version-Id` first, then falls back to `Fx-BuildId` if not present

### Implementation guidelines

1. **New integrations**: Use `Fx-Build-App-Version-Id` header
2. **Existing integrations**: Will continue to work during migration period
3. **Client considerations**: Existing client instances may continue sending `Fx-BuildId` until they are updated

### Timeline considerations

Client applications with long-running instances may continue using the legacy `Fx-BuildId` header until those instances complete their processes and are updated to use the new header format.