1. Will my existing DAM benchmarks and reports keep working after the change?

Yes. After the update, your existing DAM configurations that use the current SX-based setup will keep working. The new productized solution is added next to the old one so that consultants can migrate setups gradually.

2. Do I need to change my existing DAM SQL?

No. The SQL in the Data Aggregation Properties business object is reused. The design explicitly states that the SQL “should not have to be changed” when moving to the new solution.

3. What new screen or step will I see in DAM?

In the Data Aggregation TSI, a new step will be added at aggregation definition level, called “Aggregation parameters”. This uses the new Data aggregation parameters BO and replaces the technical SX parameter dialogs with a normal Planon screen that can be authorized.

4. Who will move the SX configuration into the new “Aggregation parameters” BO?

This will be done manually by consultants or admins. There is no automatic migration. The reasoning is that most customers only have a limited number of aggregation definitions, so copying the SX parameter strings into the new BO is considered a small, one-off effort.

5. How do I trigger the creation or refresh of aggregation data in the new setup?

Instead of running automatically on every save, a new Action is introduced: Create/Update aggregation data records.

This action can be started explicitly or scheduled (for example via Alert condition), giving you more control over when data is (re)built.

6. How is the “report” part of DAM triggered in the new setup?

The report logic keeps using status changes on the aggregation definition, just like today.

The parameter that tried to distinguish “on every update” vs “only on status change” is effectively dropped, and the system will rely on a status change to run the logic.

7. What happens if there are no data records yet when the report logic runs?

Behavior stays as it is now: if there are no data records on the data level, the logic simply does nothing and does not throw an error. This can happen, for example, if you change the definition’s status before running

8. How is DAM SQL being made safer?

A new system setting is added under System settings → Security → SQL validation:

Default No: keeps the existing basic protection (blocks DELETE, UPDATE, DROP).

Yes: applies the same, stricter protection as the Self-Service SQL feature.

9. What happens to the existing DAM SX’s (ContainerSX and ReportSX)?

Their logic will be moved into the product. The SX’s themselves will eventually be disabled using an existing Improved feature.

Until that switch is enabled, both the SX-based behavior and the new productized behavior can coexist, governed by simple rules.

10. How do old and new DAM configurations coexist on the same environment?

If the Aggregation parameters reference on the Aggregation definition is empty:

If that reference is filled:

When saving a definition, validations will help you resolve errors or warnings.

11. Will CalculateSX become part of the standard product?

No. CalculateSX will not be productized. It relies on direct database queries, which can cause performance and stability issues and are not acceptable for security and supportability reasons.