Vizlib Writeback Settings - Concurrency Handling

You can edit Vizlib Writeback Table concurrently with other users or in a browser with multiple tabs open. The following features help you manage the Writeback Table’s behavior when it’s being edited by many users or when you edit the Table in multiple tabs:

Row Locking - the software automatically locks edited rows.
Allow Manual Locking - enables any user to lock one or more destinations so that other users can’t do the writeback.
Scheduled Reload Tasks - enables you to coordinate writeback operations with Qlik Sense scheduled reload tasks.
Hybrid Mode - Vizlib Writeback Table displays values saved through writeback operations for each user before a data reload occurs.

The concurrency handling features are available when you're creating a new destination or editing an existing one in Vizlib Management Console (VMC) > Writeback Settings > Destinations.

Vizlib offers a Read-Only Mode for Users with Unallocated Licenses for users whose license is unallocated in Vizlib Management Console. The software automatically switches to this mode when changes to user license allocation are detected.

Row Locking

When you enable the Row locking feature, the software locks particular rows in the Writeback Table if these rows are being edited. This is to prevent a situation in which multiple users are editing the same row. When other users are editing the same Writeback Table, the software automatically locks the rows they are editing, and the rows become read-only for you. The rows that you’re editing are also locked for other users.

Figure 1: Locked rows.

The Row locking feature applies to Vizlib Server-based Writeback destinations. You can enable the feature on a destination level. Row locking applies to all Writeback Tables connected to such a destination. For the row locking to work, you need to have a Writeback Table with the Key columns configured. Row locking is inactive if the key columns aren’t configured. For more information on the Key columns, see Using Key Columns with Writeback in Vizlib Collaboration.

You can enable Row locking in the VMC > Writeback Settings > Destinations after you select a specific destination.

The row you’re working on is locked for other users if you’re editing a cell or when you redo an action within a cell.

Note: Locks are applied per user session—if you’re editing the Writeback Table in a different tab, you’re treated as another user and the software locks rows.

Note: Focus applied in the text field doesn’t cause row locking.

The row you’re editing is unlocked in the following situations:

When you commit your changes.
When you close the browser tab.
When your Qlik session expires.
When you undo the changes within a cell.

Row Locking and Other Concurrency-Related Features

When Row Locking is enabled in combination with No Reload or Hybrid Mode, the following behavior applies:

When a user begins editing a cell in a row, that row is locked for all other users.
After the user exports their changes, the row is automatically unlocked for everyone. This holds true before and after a browser refresh.
The edited cell retains its hybrid value and remains editable by any user.
If any user subsequently edits the same row, it is locked again for all other users until the next export.

Allow Manual Locking

There’s also the Allow manual locking feature available. When you enable this feature, any user can lock the destination within any connected writeback extension so that other users can't do the writeback. With the following options, you can decide what destinations manual locking applies to:

Lock only the current destination—disables writeback for other users in the current destination.
Use Lock Group—disables writeback in all destinations in a particular lock group.

With the Allow manual locking feature enabled, any user can lock the destination using the button at the bottom of the Writeback Table.

The Allow manual locking option is available in the VMC > Writeback Settings > Destinations after you select a specific destination.

The Row locking option and the Allow manual locking option can be enabled at the same time.

For more information on using lock groups in manual locking, see Destination Locking, Lock Groups, Queue.

Scheduled Reload Tasks

The Scheduled Reload Tasks feature enables seamless coordination between Vizlib Writeback operations and Qlik Sense scheduled reload tasks. This feature ensures that writeback operations and scheduled reloads don't conflict with each other, preventing data integrity issues and reload failures. The feature is supported for Qlik Sense Enterprise.

The Scheduled Reload Tasks feature prevents conflicts between writeback operations and scheduled reloads in Qlik Sense. It automatically manages when writebacks can occur based on your reload schedule. If a conflict happens, the system will retry the operation automatically.

Configure Scheduled Reload Tasks

To configure the Scheduled Reload Task feature, follow these steps:

Navigate to VMC > Writeback Settings > Destinations.
(New destination) Click the Add Destination button. The Add Destination modal window opens.

(Existing destination) Enter an existing destination.
(New destination) Configure the destination settings and locate the Locking section.

(Existing destination) Locate the Locking section.
Click on the Scheduled Reload Task field. The system displays available tasks from your Qlik Sense environment.
Select a task. The Lock Destination Before field displays. This enables you to configure when the destination is locked before the scheduled task.
Enter time values manually or select them from a dropdown .

Note: insightsoftware recommends you set the values based on your writeback operation duration (for example 1 minute for standard operations).

The destination will display the linked reload task name and schedule. A lock icon appears when the destination is locked for a scheduled reload. The system automatically locks the destination and queues any writeback attempts during the lock period. The system automatically retries any failed operations and unlocks the destination when the reload completes.

Additionally, you can configure the following settings:

Maximum Retries: Number of retry attempts (default: 5)

Range: 0-10 retries.

Set to 0 to disable retries.
Retry Interval: Time between retry attempts (default: 20 seconds)

Range: 5 seconds to 5 minutes.

Consider your typical reload duration when setting this value.

Limitations

The following limitations apply:

The Scheduled Reload Task feature cannot be used when dynamic tags for reload are enabled.
Automatic locks from scheduled tasks take priority over manual user locks.

Hybrid Mode

With the Hybrid Mode feature, Vizlib Writeback Table displays values saved through writeback operations before a data reload occurs. This feature enables users to immediately and persistently see the data they have entered, even after page refresh or opening new browser tabs, without waiting for a data reload to complete. Also, the users get real-time information if someone else is editing the data.

Once the data reload happens, the saved values are replaced with the actual data from the data model. Because the data model reflects the previously saved values, the transition is seamless.

Hybrid Mode is supported in both Server-side deployments and Serverless (Client-Side) deployments. The following behavior applies to each deployment:

In Client-Side deployments, Hybrid Mode operates on the client side. Each user sees their own saved changes persistently until the next data reload. This implementation is designed for scenarios where each data cell is edited by only one user — there is no built-in concurrency control across multiple users.
In Server-Side deployments, Hybrid Mode operates on the server side through Vizlib Server. Unlike the Client-Side implementation, saved data (hybrid rows) is managed centrally by the server, which provides concurrency control for environments where multiple users may interact with the same data. Hybrid rows are persisted on the server and are retained even after a reload.

With the Hybrid Mode feature enabled in Writeback Table in both Client-Side and Server-Side deployments, the software displays a tooltip on hover, indicating three different data states:

Original value: Data fetched during the last reload.
Current value: Values changed within the current session but not yet written back.
Saved value (hybrid value): Values that have been changed and written back, but not yet reloaded from the data model.

Hybrid Mode Configuration Prerequisites

Before you enable Hybrid Mode in any deployment, make sure the following requirements are fulfilled:

At least one column is configured as a key column.
Alternatively, the writeback destination or destination settings for the Update/Delete option are equal to Match rows byPrimary Key and there's at least one primary key in the destination table.

Enabling Client-Side Hybrid Mode

To enable Client-Side Hybrid Mode, follow these steps:

Navigate to the Property Panel > Writeback Settings > Engine Settings.
Locate the Hybrid Mode option.
Change the Hybrid Mode toggle to Enabled to activate the feature for the extension.

Result: When Client-Side Hybrid Mode is enabled, users will see visual indicators differentiating between the three data states. Saved values will persist in the interface after writeback operations, providing immediate visual feedback that data has been successfully saved. These saved values remain visible across page refreshes and new browser sessions until the next data reload occurs.

Enabling Server-Side Hybrid Mode

To enable Server-Side Hybrid Mode, follow these steps:

Navigate to VMC > Writeback Settings > Destinations.
Click on the destination you want to configure. The Edit destination modal opens.
In the Writeback Settings section of the modal, locate the Server Side Hybrid Mode checkbox.
Select the checkbox to enable Server Side Hybrid Mode for this destination.

When Server Side Hybrid Mode is enabled, the server handles concurrency for multiple users working with the same destination.

Result: When Server-Side Hybrid Mode is enabled, saved values (hybrid rows) are managed centrally by Vizlib Server and persist across all user sessions. Users will see visual indicators differentiating between the three data states, providing immediate visual feedback that data has been successfully saved. Because hybrid rows are stored on the server, all users accessing the same destination see the same saved values, and concurrency control ensures consistent behavior when multiple users interact with the same data. These saved values remain visible until the next data reload replaces them with the actual data from the data model.

Hybrid Mode Property Behavior for Server-Side

The visibility of the Hybrid Mode property in the Writeback Table extension's Property Panel depends on the Server Side Hybrid Mode setting in VMC:

Server Side Hybrid Mode enabled in VMC — The Hybrid Mode property is hidden in the Writeback Table Property Panel. The server controls Hybrid Mode centrally and manages concurrency for multiple users.
Server Side Hybrid Mode disabled in VMC — The Hybrid Mode property remains visible in the Writeback Table Property Panel. Users can toggle Hybrid Mode, but it operates in client-side mode only with no multi-user concurrency control.

When Server Side Hybrid Mode is disabled in VMC and a user enables Hybrid Mode from the Writeback Table Property Panel, the feature operates in client-side mode only. In this scenario, there is no server-managed concurrency control, and the same single-user editing limitations as client-side deployments apply.

Hybrid Mode Limitations

Server-Side and Client-Side Hybrid Mode are not supported for REST destinations.

Read-Only Mode for Users with Unallocated Licenses

When a user's license is unallocated in the Vizlib Management Console (VMC), the Writeback Table and Input Form extensions automatically switch to read-only mode. In this mode, users can still view existing data, but all editing and writeback capabilities are disabled.

When Vizlib Writeback Table enters the read-only mode, you can notice the following changes:

All table cells become non-editable. Data remains visible but cannot be modified.
The Writeback data button is disabled.
The context menu no longer includes the Paste and Add Row options.

When Vizlib Input Form enters the read-only mode, you can notice the following changes:

All form fields become non-editable. Data remains visible but cannot be modified.
The Writeback data button is disabled.