If I wanted to embed a dashboard that had a field ...
# gooddata-cloud
r
If I wanted to embed a dashboard that had a field we could pass as a filter to dynamically filter depending on who's viewing, is that something that's doable?
j
Hi Ryan, We've discussed the same topic in the below thread: https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1751368338183029 There are some technical recommendations and also things to be aware of.
r
So if I understand; it's not recommended as there's bypasses that could exist, but can be done?
j
yes, that's correct. Its not a security feature for sure, end users would be still able to pick any other value from the filter.
so doable, however recommended with UDFs or WDFs
r
So - the value would end up in a wdf field. Example; we're working on a heavy PLG approach this quarter, and looking at how we can deliver a single report that would filter on our tenant_id, which is a wdf in our setup. However, we're going to avoid building them a workspace until they actually convert to being a full customer, not a lite version.
j
yes that should work, if the workspace in question contains active WDF filter, it would be applied even in embedded environment. Same goes for UDFs.
r
so - we have our core space, our base space. Call it TRB. We want to be able to create a report in TRB, that's filtered on
wdf__tenant_id
= <TENANT_ID> as identified by the login into our web based portal. So we want to be able to filter on that. It won't be in a workspace where the
wdf__tenant_id = <TENANT_ID>
j
You cannot filter in parent workspace. You are only setting WDF there, but the actual filtering is happening in child workspaces where you set the filter setting.
In case you would need to filter in Parent Workspace, I would recommend to use UDFs which you can set on specific user or userGroup.
r
Can you set a UDF that's aligned on the wdf itself?
j
If we are talking about parent workspace, there's no "collision" at all as no filtering is actually happening there. If we are talking about child workspace where active filtering is happening due to WDF setting - then the interaction with UDF is always intersection (AND operator).
For example: In a situation where the WDF setting allows visibility for 3 rows in a column, but the UDF additionally restricts visibility to only 2 of those rows, the user will end up seeing only those 2 rows. I hope that makes sense.
If WDF and UDF would be set for different rows (no intersection) the result will be No data - uncomputable report.
r
Right. The goal here is we're trying to get people to sign up and set up their own small account (< 5 users). So we would auto-generate a tenant_id, and then we want to facilitate a dashboard that is embedded in our web portal with this data w/o us having to buy a new workspace.
so we generate
wdf__tenant_id = abc123
unique, and UUID. Then we want to have that passed into a core dashboard in our parent space that would pass the
wdf__tenant_id
as a filter to the dashboard.
j
Just to be sure that we are on the same page — what you're describing won't work as expected if you're trying to filter in the parent workspace using
wdf__tenant_id
. • WDFs only control what data is visible in child workspaces. • No actual filtering happens in the parent workspace, even if the WDF is defined there. So if you're embedding a dashboard from the parent workspace and want it to be dynamically filtered per viewer, you'll need to use UDFs instead of WDFs.