Hello,

On my side I have a very practical use case with a customer. They are using an application which is leveraging a dimension to store changes.

Given their model is very complex, with multiple layers of calculations inter-dependent and stores tens of thousands of changes, each change takes a bit of time to process, but if you have a lot of users making changes at the same time and with a lot of drivers, then it takes a while which is not ideal from customer perspective.

As such, the customer decided to build a “Light” application, where only core features are present, so that it runs much faster, and key users can make draft changes to see the result in the Light application before replicating in the main application. Of course, as you can imagine, replicating changes manually poses different difficulties, and it’s not sustainable in the long run.

Now with this new feature, we finally have something natively built in Pigment, and that removes the need for customer to replicate changes in both app.

Hope it’s clear
 

Hello,

The two use cases I anticipate the most for this feature are performance optimization and a basic input validation flow.

1. Performance Optimization

Currently, when users input data directly into a List, all downstream calculations are triggered immediately. With the List-to-List copy feature, users can first input their data in a staging List, disconnected from the rest of the model. Once ready, they can trigger a copy operation, which consolidates all changes and triggers a single batch of recalculations. This reduces computational load and improves performance, especially in complex models.

2. Input Validation

This mechanism also opens the door to lightweight validation flows. For instance, you could define a Boolean property computed with a formula to check certain conditions—such as whether a text property exceeds a specific length, or if another property is non-empty. With the filtering capabilities of the List-to-List import, you can then prevent users from copying data that does not meet these conditions. This provides a way to enforce simple validation rules without complex workflows.

That said, we’re excited to see what other use cases our customers will imagine for this feature. In the coming weeks, we’ll gather the most popular examples and consolidate them into a comprehensive guide.

Best,
Pierre

Just came across another super helpful use case.
A client accidentally deleted items from their transaction list. Thankfully, we were able to restore everything using the Restore Blocks feature combined to this one. It worked like a charm to bring the transaction list back to its previous state.

For the Input validation case it would be great if I could add both the original import and the respective List-List import to a single Data flow, so that they both would happen with a single button click

Hi ​@Pierre for the performance optimization, would it not be better using the feature to not automatically save inputs?
 

And for the data validation, given that data is coming from a list, would we not just use the boolean property as a filter in the metric formula to exclude any data that doesn’t meet the criteria and also as a way to filter the output on the boards?

For me, I anticipate gaining value of this feature by now using transaction lists where we previously had to build metric-based table inputs (e.g. employee overrides or TBH in employee based workforce app). With list to list imports, we can now start versioning data by having one “live” set of data where version is blank, and then copy that data on demand to save down a copy as Reforecast Q2 etc, which would be read-only. Having a transaction list as input makes things like filtering etc much easier, but the versioning aspect was a blocker in the past.

The second benefit for me is avoiding involvement of external ETL tools / IT team for simple filters or transformations. For example, one customer had workforce data coming in with an employee UID consisting of employee ID AND cost center ID. A change in cost center therefore would lead to another employee item. We created a second dimension to map and had to create an additional ETL process outside Pigment. With list to list, we can have a staging transaction list and a final one, to transform data via formulas and new properties, and then importing them into another transaction list (and dimension list).