Hey,

I’d like to share my thoughts on this, as I believe the situation might be more complex than it seems, and I feel you might be using a workaround to address a problem that could be tackled differently.

If the core issue revolves around who can view specific data, you could leverage built-in catalog tools and permission settings to control data access at a more granular level. Instead of relying on the ‘run as’ parameter, you could implement access controls using catalog-level permissions, ensuring that users can only read the data they are authorized to see.

Additionally, if you need to generate results after data wrangling, a more scalable approach would be to create dynamic views, allowing only specific users (through groups) to have visibility over certain data. This can be achieved using a SQL view with conditional logic, such as:

CREATE OR REPLACE VIEW filtered_data AS 
SELECT * 
FROM raw_data 
WHERE 
  CASE 
    WHEN current_user IN ('user1', 'user2') THEN sensitive_column 
    ELSE NULL 
  END;

Unlike manual adjustments in the workflow execution settings, which can introduce operational risks and dependencies on user actions, catalog-level permissions ensure consistent data governance and security across all workloads.

If you find this answer helpful, feel free to mark it as resolved or give it a 👍!

🙂