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 š!
š