I am new to PowerBI. I have several stores. Now I want to make generic reports for all the stores. All the stores can see same reports. But the data for all the reports would be respective. That means particular store can see the data for itself. How can we achieve that?
I believe what you are trying to do can be achieved with row level security.
https://learn.microsoft.com/en-us/power-bi/service-admin-rls
Basically, you create roles for your reports which filter the data that is available to be seen by the people or groups that you assign to the roles.
E.g., if you had a Chicago store, you could create a "Chicago" role that filtered your data to only return parts of your data table (a filter specified like Store[City] = "Chicago") and then you'd give the relevant individuals or groups from Chicago that role so they'd be able to see that data.
Related
I have an application being built using AWS AppSync with a primary focus of sending telemetry data from a mobile application. I am stuck on how to partition and structure the DynamoDB tables for this as the users of the application belong to different organizations, in those organizations there will be admins who are able to view the data specific to their organization.
OrganizationA
-->Admin # View all the telemetry data
---->User # Send the telemetry data from their mobile application
Based on some research from these resources,
Link 1.
Link 2.
The advised manner is to create tables for individual periods i.e., a table for every day with the telemetry readings.
Example(not sure what pk is in this example):
The way in which I am planning to separate the users using AWS Cognito is by attaching a custom attribute when the user signs up such as Organization and Role(Admin or User) as per this answer then use a Pre-Signup Lambda Trigger.
How should I achieve this?
Since you really don't need users from one organization to read data from another organization, and for all your access patterns you will always know the organization id, then that attribute should be a factor in partitioning: either at the table level, or at the partition key level.
Then you have to determine if you can simply use the organization id as a partition key, or you need to further partition -- say, by concatenating the organization id and the hour value for each sample. This will depend on the amount of data you expect to generate by each organization in a given day. The tradeoff being more granular partitioning vs. cost of querying for data.
If organizations generate small amounts of data each day (say, a few events an hour) then just use organization id as the partition key. Otherwise, partition the data further.
In all of the above, the sort key should probably be the timestamp of the events, either with second or millisecond precision depending on your needs. That way your queries can retrieve ordered time-series data.
Keep in mind that when you make queries, you may need to execute multiple queries and stick the results together in your application to fully represent the results as the range may span multiple partitions, or even multiple tables.
I'm kind of new to PBI and I'm looking if it's the right tool for my case.
I would like to use Power BI Embedded in a web application for our customer (where they're logged in) which do not have any Power BI account/licence.
The database on which the reports are based are on-premise so we're would use Analysis Service Live Connection to access them.
Each customer should have his own report.
Is it possible to use RLS in that case?
Does that mean we've to create a role for each of them?
What username should be given in the EffectiveIdentity? Is it 'free text' that is used by PBI to get the username in the DAX?
If each customer will have his own report, then why do you need RLS at all? Just make the report to show what the user is supposed to see. Or you want to have a single report (or set of reports), which is shared between the users and they should see only their data? I will assume it is the later one.
I will start with the last question - the effective identity is not a "free text". It must be a valid user name, having rights to access the data, as specified in the documentation:
The effective identity that is provided for the username property must be a Windows user with permissions on the Analysis Services server.
The you can define RLS in your Analysis Service model, by adding a "users security" table, where you specify which rows should be visible to each user. Define relationships between this users security table and other tables in the model, and then let RLS to filter the data in the security table. The relationships with the rest of the model will apply cascade filtering on the data, so only relevant rows will be visible to the user. See Implement row-level security in an Analysis Services tabular model for example.
So the answer of your second question is no, you don't need a separate role for each user, because the filtering is based on the username and for every user it filters the same thing the same way.
I have created a Dataflow in power bi service. Now my client's requirements is that they want to take the data from the dataflow as per the roles. There is a user table where roles are already defined. My question is that without the relation between tables, how I am supposed to filter the data from all the tables? Is it possible at all? Or how can I make relationship of the tables in dataflow? Or any alternate procedure to take the data from dataflow as per the roles. Help me pls. Thanks in advance.
If your data supports it, for example some sort of mapping between the user and the data they are allowed to see, you will need to use Row Level Security to restrict what the end users see in the report. You will make the relationship between your dataflow and mapping table in Power BI, not the dataflow.
If you mean restricting access to the data in the dataflow based on their role, for example the user creates a report it only loads what they are allowed to see, then this functionality is not supported.
Hope that helps
I have one dashboards one with all data from all countries, and I would like one single dashboard for each country reusing the previous dataset. I would like to do that to minimize the space needed in cloud for those dashboards. Also there is users that only should have access to data to each own country.
I tried to create a parameter to filter by country but it is not allowed when I reuse a data set as data source.
Could you please help me to find a way to reuse dataset filtering by country in order to minimize the resources needed?
Thanks in advance
Either use Row-level security to define which rows should be visible to the current user, or make separate reports for each country and share the data source between them. If you use Direct Query, there will be single copy of the data. Or you can publish one report with data for all countries to the cloud, and use it as a data source for the per-country reports.
This is related to Row-level security in Power BI. Here is a dummy table on which I want to implement this RLS.
The RLS formula I am using right now is -
[location] = LOOKUPVALUE([location],[login],USERPRINCIPALNAME())
My end requirement is to make this RLS work on the case where if a user logs in he should see the data if the location he is in and also should see other users who are in the same location.
But lookup is throwing an error:
A table of multiple values was supplied where a single value was expected
Also, a single user can have access to multiple location and a single location could have multiple users.
How I can achieve this level of Row-level security using either Lookup or using any other possible way?
Your requirement can also be done through this way, you need to work on both the Power BI desktop and app server to get this right.
In Desktop
Power BI Desktop allows you to create Roles.Click on Manage Roles
and then click on Create New Role.
You would need to create Roles based on the Location here.
For Example Create a rule Called as Location A and click on the
table and give the formula to filters on that table. For example,
[Location] = "A".
So, you can create 'n' number of roles like this and then publish the dashboard.
App.PowerBI.Com
Now, Open app.powerbi.com and then go to the corresponding dataset and
right click on it, select security - you will find the groups there.
On the Groups, enter the emailid's that should have access to it.
You can add a person in multiple groups, that will allow them to see
more than one group.
Testing
Desktop allows you to test it as well - you can click on view as
roles, to see what the user in that group sees.
Also to remember, only people who have access to the dashboard will be able to see the data inside it. So, you will need to share it with them and as well as need to add them inside the groups. If you fail to do one of it, then they won't see anything on the dashboard.
Most efficient Method
This is a better method and I think this is the one you are asking for,
[login] = username()
The function username() automatically gets the email address of the user that is logged in.
Create the above mentioned filter on the new role in the required table.
This way, you would still be adding those 50000 users manually inside the roles under the security section of the corresponding dataset.
But If they all belong to a particular group in an organization, and your Office-365 team has configured your back-end in the right way, then you will only need to enter the group.
But most companies don't have this configuration on their back-end as it is very difficult to control the data security.
Change the Data Model
To do your requirement, you also need to change your data model.
You will need to have two tables initially.
The Value Table - You can have many columns like name and all in there, but it doesn't matter.
The Email Address Table For Location as your second table.
Now Merge the Locations from Value Table to Email Address Table and that will be your final Table. Use this for visualizations but please be very clear on DAX - as you may have duplicate rows and different values.
Now Create RLS on this Table. It should work.
As the name goes, Row Level Security is applied on each rows. So, the formula will be evaluated for each row individually. So, your only option is to have a flat table with all the values.
I answered a question very similar to this one on another page. I will copy it here because I added a bit for the lookup function.
Embedded Power BI: Add Multiple Users in Row Level Security and assign different roles
If you have more than one data to filter against in a role, pass the list as a string path to RLS, parse it into a table, then return the row when it matches with a value in the column.
We do this if we are not actually passing username, but for cases like multiple sales offices, or making a view that compares data from multiple user accounts, or when a user belongs to different hierarchies in an organization, or basically any time you want to use multiple filters..
example input using sales ids
//Username() = "020104010|020104061|020104303|020104304"
//DAX
var userIds = Username()
VAR tbl=
GENERATE (
GENERATESERIES(1,PATHLENGTH(UserIds),1),
ROW ( "Key", PATHITEM ( userIds, [value]))
)
VAR valueList =
SELECTCOLUMNS ( tbl, "Key", [Key] )
return [sales_id_column] in valueList
If you need to add lookup functions, you can apply it when the ROW() statement is called.. it will look like this:
VAR tbl=
GENERATE (
GENERATESERIES(1,PATHLENGTH(UserIds),1),
VAR CurrentKey = [Value]
RETURN
ROW ( "Key", LOOKUPVALUE(Table[c1],Table[c2], PATHITEM ( userIds, CurrentKey )))
)
There is also a case when the table has a many to many relationship and cannot use multiple roles as identity. Or for this case specifically when you only want to use one role to filter many tables. In that case the username looks like this:
Username() = "Username:Bob|Location:A|Location:C"
The code will have an extra step to parse the inner path after you change the ":" to a "|". Then use a if conditional to check if the current table filters for this role. This approach supports a claims-based authorization where only one role needs to be created in RLS and everything can be done client-application side.
runtime is O(k(n log m)) where m is the number of claims you have applying RLS in the current table, n is the number of rows in the table, and k is the number of tables you are applying RLS on