Title
Create new category
Edit page index title
Edit category
Edit link
Ensuring Data Share Persistence During Table Recreation in Snowflake
Ensuring Data Share Persistence During Table Recreation in Snowflake
Problem:
Infoworks pipelines in overwrite mode that write to Snowflake will drop and recreate the target table. If the target table is dropped ,the table's Object ID is deleted causing broken shares or views.
Recreating the table with the same name does not restore downstream dependencies.
Solution:
Use a Snowflake Dynamic Table as a Stable Proxy, dynamic tables have a stable Object ID.
Views/Shares will be created based on the dynamic table instead of Infoworks landing table

Base Dynamic Table Definition example
Replace dynamic table db, schema and table name along with Infoworks landing table name and warehouse.
Consumers must now reference only the Dynamic Table, never the Infoworks landing table.
The dynamic table must be refreshedto update data from Infoworks landing table.
Below are the options to refresh the table automatically based on usecase and required refresh frequency.
Option 1: Automatic Refresh Using TARGET_LAG
The dynamic table is refreshed every 12 hours
Option 2: Cron‑Based Snowflake Task
A Snowflake Task periodically triggers a refresh.
Recommended when batch‑aligned refresh is acceptable
Option 3: Event‑Driven Refresh via Infoworks Bash Node (Snowflake API)
Infoworks workflows can include a Bash node that runs after the Snowflake export job and explicitly triggers a Dynamic Table refresh using the Snowflake REST API. An alternate option is to use pipeline post hook job to call the snowflake rest api.
This provides true event‑driven behavior.
Get Snowflake OAuth Token and call Snowflake API to Refresh Dynamic Table
Env : Infoworks 5.5.3
For more details, refer to our Knowledge Base and Best Practices!
For help, contact our support team!
© UNIPHORE TECHNOLOGIES 2025 | Confidential