> ## 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 order that we recommend for post-deployment configuration of FlowX.AI.

## Redis cache clearing

<Warning>
  **Cache Clearing**:

  * FlowX.AI 5.1.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.1.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.1.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.1.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 auth-system will automatically:

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

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

    * Migrate existing projects from app-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.