Original subtitles

Next up want to take just a minute to talk about managing and viewing as roles now within the modeling

tab you'll see a security tool group with two options and you clicked the manager roles option.

It allows you to actually define filtered views so that your report can be tailored to specific audiences.

So in this case we're choosing to filter down the territory lookup table based on the condition or the

expression that the continent fields must equal Europe and you can create a number of different roles

based on different daks filter expressions.

So in this case here we've created views for each territory manager Europe North America and Pacific

based on those simple daks filter statements continent equals Europe consonant equals North America

etc..

Now it's important to make clear is that you're not just pointing a user to a pre-filter view.

So when you select the Europe role that we've created for instance you're not seeing the Executive Summary

tab pre-filter down to Europe you're seeing a version of the report that literally doesn't contain data

for any other continent.

And that's why this is different from simply creating a bookmark or prefilter view that you can link

to.

This is actually running the selected table through a daks filter expression and chopping out rows that

don't meet the condition.

So what we're dealing with here is essentially row level security meaning we're defining specifically

what rows of our dataset certain users or user groups are able to access.

So this is very simple to set up.

Let's head to power be-I and I'll show you how this works.

All right so back in our Exec Summary tab what we're going to do here is head to the modeling time click

on security manager roles.

This is where we create or define a new role.

And just like the example we talked about let's create individual roles for each territory so that we

can provide Adventure Works.

Sales managers from different regions with reports that only contain the data that's relevant to them.

So let's start with a roll named Europe and basically we define which table we need to filter down.

In this case the only table that we need to filter is the A.W. territories look up and then we write

a simple daks filter expression that returns a true false value.

So in this case continent equals

Europe.

It's as simple as that.

Now I was a little icon tells us that this is the table that's filtered and in the window here we see

the expression that defines the filter.

So press save.

There we go.

And now we click view as rolls we have a Europe as an option here.

So watch what happens and pay very close attention specifically to our map and to our map slicer we

click Europe press OK.

See what happened.

We are now filtered on Europe but our continent slicer only contains a single value aside from select

all which is euro.

So that really emphasizes the difference between simply creating a filtered view and actually defining

row level security that prevents rows of data from actually reaching the report.

So from here we can simply say stop doing back to normal can manage rels create another for Pacific

territory look up and write the same kind of expression for Pacific instead of Europe.

Save you as roles rolls.

No we've got a Pacific option as well.

And there you go.

Same thing.

So a Pacific sales manager in this example has no idea that data from Europe or North America is tied

into this model or even exists.

So it's a great tool when you have sensitive information or need to create very specific access rights

for certain user groups or teams in your organization.

So let's go ahead and stop viewing Pacific.

Now one thing worth calling out here is that by implementing relevel security rules this does have impacts

in other places and one area is when it comes to actually publishing reports.

Now again publishing and collaborating will be covered in depth in an entirely separate focused course

but it will provide a quick preview on what it looks like to load this to service.

Now if I have ro level security roles defined that prevents me from publishing this to the Web.

So in this case I don't really need those rules so I'm going to go back and delete the two that we created

just so that later on I can demo what that publish to web functionality really looks like so save.

And now we're back to usual.

We've got no additional roles and that should do it.

So good intro to pro-level security and using Proby as manager roles options.