datagroup_trigger lets you specify the datagroup to use as a caching policy for the derived table. The datagroup itself is defined in the model file using the datagroup parameter.
Adding the datagroup_trigger parameter to a derived table makes the derived table a persistent derived table (PDT). The table is written into a scratch schema on your database and regenerated as specified by the datagroup parameter.
If you use datagroup_trigger for your PDT, you don't need to use the sql_trigger_value or persist_for parameters. If you do, you will get a warning in the Looker IDE, and only the datagroup_trigger will be used.
Examples
Create a persistent native derived table called customer_orders that is rebuilt when triggered by the datagroup named order_datagroup:
Create a customer_orders persistent derived table based on a SQL query that is rebuilt when triggered by the datagroup called etl_datagroup:
view: customer_orders {
derived_table: {
sql:
SELECT
customer_id,
COUNT(*) AS lifetime_orders
FROM
order
GROUP BY 1 ;;
datagroup_trigger: etl_datagroup
}
}
Common challenges
If you have PDTs that are dependent on other PDTs, be careful not to specify incompatible datagroup caching policies.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-07-22 UTC."],[],[],null,["# datagroup_trigger\n\n\u003cbr /\u003e\n\nUsage\n-----\n\n```\nview: my_view {\n derived_table: {\n datagroup_trigger: my_datagroup\n ...\n }\n}\n```\n\nDefinition\n----------\n\n`datagroup_trigger` lets you specify the datagroup to use as a caching policy for the derived table. The datagroup itself is defined in the model file using the [`datagroup`](/looker/docs/reference/param-model-datagroup) parameter.\n\nAdding the `datagroup_trigger` parameter to a derived table makes the derived table a [persistent derived table (PDT)](/looker/docs/derived-tables#persistent_derived_table). The table is written into a scratch schema on your database and regenerated as specified by the `datagroup` parameter.\n\nIf you use `datagroup_trigger` for your PDT, you don't need to use the [`sql_trigger_value`](/looker/docs/reference/param-view-sql-trigger-value) or [`persist_for`](/looker/docs/reference/param-view-persist-for-for-derived-table) parameters. If you do, you will get a warning in the Looker IDE, and only the `datagroup_trigger` will be used.\n\nExamples\n--------\n\nCreate a persistent [native derived table](/looker/docs/creating-ndts) called `customer_orders` that is rebuilt when triggered by the datagroup named `order_datagroup`: \n\n view: customer_orders {\n derived_table: {\n explore_source: order {\n column: customer_id { field: order.customer_id }\n column: lifetime_orders { field: order.lifetime_orders }\n }\n datagroup_trigger: order_datagroup\n }\n }\n\nCreate a `customer_orders` persistent derived table based on a SQL query that is rebuilt when triggered by the datagroup called `etl_datagroup`: \n\n view: customer_orders {\n derived_table: {\n sql:\n SELECT\n customer_id,\n COUNT(*) AS lifetime_orders\n FROM\n order\n GROUP BY 1 ;;\n datagroup_trigger: etl_datagroup\n }\n }\n\nCommon challenges\n-----------------\n\nIf you have PDTs that are dependent on other PDTs, be careful not to specify incompatible datagroup caching policies."]]