Skip to main content
Solved

Table Source Behavior When Switching to Central Extraction Pool

  • November 11, 2025
  • 3 replies
  • 14 views

Oli
Level 3
Forum|alt.badge.img
  • Level 3
  • 3 replies

Hi everyone,

we are currently restructuring our data architecture in Celonis. For each process area (P2P, AP, AR), we have separate data pools where we extract, transform, and load the respective data models.

In the AP area, we already use a dedicated Central Extraction Pool, which only handles the extraction of raw tables. The actual AP data pool then receives these extracted tables and performs the transformations.

Now, we want to extend this concept gradually to other areas. For example, we plan to stop extracting the CDPOS table in the Purchasing Pool and instead consume it from the Central Pool. This step-by-step migration should help us reduce redundancy and improve maintainability.

However, I have a specific question regarding this setup: If I start consuming tables from the Central Pool in the Purchasing Pool (e.g., CDPOS), what happens to other tables like EKKO, which are still being extracted directly in the Purchasing Pool?
Will my transformations in the Purchasing Pool use the locally extracted EKKO table, or will they automatically switch to the EKKO table from the Central Pool, assuming it exists there too?

I want to avoid any unintended behavior or data mismatches, especially during the transition phase where some tables are still extracted locally and others are sourced from the Central Pool.

Has anyone gone through a similar migration? How does Celonis determine which version of a table is used when the same table exists in both the local and central pools?

Thanks in advance for your insights!

Best answer by jayesh.kumar.jain12

Yes right, no automatic priotization. If you miss to give the schema name in the transformation, then it will try to fetch the data from local schema where queries were written.

That’s why schema name will help with differentiation to fetch table only from required data connection.

3 replies

Forum|alt.badge.img+2

Hello, 

It requires to extract the table in central data pool and then share the data connection with other destination data pool to run transformation in destination pool.  Using feature - https://docs.celonis.com/en/sharing-data-between-data-pools.html#UUID-ad0ebb8f-87c6-06d0-58b3-0ebc87f2f25d

Your transformation will still use “the locally extracted EKKO table”. You will be required to fetch data from CDPOS (central data pool) in transformation using table by using keyword Datasource (check screenshot to refer correct table from source schema) - https://docs.celonis.com/en/creating-transformation-tasks.html#UUID-b7c4074c-28c9-cc91-c1d8-8102f2f4fe0e_section-idm4549909028411234172201645235

 

Celonis will be able to determine source of the table based on the schema name used in from clause in transformation.


Oli
Level 3
Forum|alt.badge.img
  • Author
  • Level 3
  • 3 replies
  • November 12, 2025

Thanks for the reply!
The central extraction pool is already set up and used for our AP data. In this context, we already extract tables like EKKO and CDPOS in the central pool.

From your explanation and the screenshot, it seems that I need to adjust all transformation jobs in the Purchasing Pool by explicitly adding
<%DATASOURCE:SAP_CONNECTION%>
to ensure the correct source is referenced — meaning EKKO from the Purchasing Pool and CDPOS from the Central Extraction Pool.

In the long run, we plan to extract all data through the central pool and feed all our data pools from there. However, during this transition phase, this would mean quite some extra work if every transformation needs to be adapted manually.

Just to confirm: There is no automatic prioritization of the locally extracted tables over the central extraction pool, right? The schema name in the FROM clause fully determines which version of the table is used?


Forum|alt.badge.img+2

Yes right, no automatic priotization. If you miss to give the schema name in the transformation, then it will try to fetch the data from local schema where queries were written.

That’s why schema name will help with differentiation to fetch table only from required data connection.