Forum Discussion
Microsoft EmployeeCopy Data into a new Kusto table
I ended up replacing the original KQL activity with the following sequence:
- A Lookup activity to retrieve the schema of the incoming table
- A KQL activity to drop the table if it already exists
- A KQL activity to create an empty table
- A Copy Data activity to populate the table with content
While this approach isn't fully compliant—since not all activities are workspace identity (WI) based—it’s still an improvement over the previous setup. At least the activities that interact with external databases, namely Lookup and Copy Data, are WI-based.
Microsoft EmployeeI ended up replacing the original KQL activity with the following sequence:
- A Lookup activity to retrieve the schema of the incoming table
- A KQL activity to drop the table if it already exists
- A KQL activity to create an empty table
- A Copy Data activity to populate the table with content
While this approach isn't fully compliant—since not all activities are workspace identity (WI) based—it’s still an improvement over the previous setup. At least the activities that interact with external databases, namely Lookup and Copy Data, are WI-based.
Community SupportHi Jing1018
Thanks for sharing the update. We really appreciate the detailed insights, as they will help others with similar issues. Your new sequence makes the process much clearer, especially with the structured flow from schema retrieval to data population. Even if it’s not fully WI-based, it’s definitely a step forward in ensuring stronger alignment with best practices. Highlighting the trade-offs between compliance and practicality is also really valuable, this will give others a solid reference point when they’re evaluating similar setups.
If you have any other queries, please feel free to create a new post here in the community. We are always happy to help.