Re: STT - Troubleshooting Section Access in Qlik S... - Qlik Community

A: The wildcard character * in the data reduction column refers only to all values in the security table. If there are values in Section Application that are not available in the reduction column of the security table, they will be reduced. ALL is just a value I created and reference in, which I have control over and use to help visualize the relationships.

Q: Qhat is the best practices when we have a section access based on 5 fields?

A: Create a composite key in a link table or fact table. This is your junction box.

Q: Sales person to see his sales plus sales for another departments of other Sales person?

A: Create an aggregate set of facts in your fact table that all users would have access to.

Q: Do you have to reference the long USER ID string in QS SaaS as the USER ID in Section Access, or can you use ADFS usernames?

A: Yes - Using Active Directory Federation Services (ADFS) as an IDP for Qlik Sense Enterprise SaaS

Q: Can we reduce data by numeric field that is a dimension? Can we reduce data using wilcard? For example by fields that begin with dim*?

A: Any value can be used for data reduction, but wildcards are reserved so you will want to create a secondary table to map your strings.

Q: Is there still a risk of locking yourself out of a qvf app like there was in QlikView?

A: No. You can always open without data.

Q: Although section access works with NPrinting for Qlik Sense, show/hide columns don't work with NPrinting from what I have read.

A: I have used the container show/hide on charts in NPrinting. You could also make your condition in the master item which should propagate correctly.

Q: Can i simply use multiple Reduction Fields?

A: It could create a circular reference, which is generally not desirable or could create unintended results. A composite key is best practice. - Basics for Complex Authorization

Q: In data script: what's the best practice to build up temp section access table by combining different datasources (excel, qvd) before using that under section access?

A: This is the same as building any other table. There shouldn’t be any adverse impact by concatenating tables from multiple sources for the purposes of section access.

Q: What condition did you use to show the Qlik logo vs. the section access data?

A: It was just container similar to what I did with the scatter and distribution chart. I used a text object and a filter pane in a container. It was ‘count(USERID)= 0’ and ‘count(USERID) <> 0’

Transcript:

Hello everyone, and welcome to the April edition of Support Techspert Thursdays. Today's presentation is Troubleshooting Section Access and Qlik Sense Enterprise with Mike Reese. Mike, why don't you tell us a little bit about yourself?
Thanks Troy. I’m a senior solution architect with Qlik. My main focus is helping guide customers in their Qlik journey through pre-sales, and I actually have 14 years total experience with Qlik; over six now actually working for Qlik directly and eight in the partner space: consulting, wearing various hats, implementation, architecture design, development, project management, you name it.
Great. So, Mike, what are you going to be showing us today?
Today, I will be covering Section Access. So, what is Section Access? We'll go through a couple scenarios of role base Access. We'll do some impersonation. So, you'll get a kind of a good understanding of how you could get into an application as a different user; actually test their entitlements and easily flip between the different types of Access that you might need to implement in your security model. So, then we'll also see how that is applied through the load script. And then at the end, we'll go through some data modeling tips that help facilitate Section Access; and different levels of facts, different types of facts, multi-fact table and being able to set up security in a seamless way. And then also, we'll go through our takeaways and tips and tricks.
Great. So, how does Section Access work?
Good segue. I just have a couple slides to help frame the demo, and then a few more to reinforce what I show. Data authorization using Section Access is implemented using reserve words as field names and values for your entitlements table where Access levels aren't assigned to users within the Section Access part of the script. These tables must contain a minimum of two system fields; Access being one of them. As you come in, a user logs into the application; they're either designated as an ADMIN through this Access keyword, or a USER. And if you're an ADMIN, you have Access to all the data. And if you're a USER, then you have Access to reduce sets of data based on whatever is designated to you in this entitlements table that's set up in the load script.
Okay. So, it's all about controlling the data that's shown to the user based on their profile?
That's right. So, literally you're setting up an entitlements table and through the power of Qlik’s Associative Model; those associations designate what a user can see and what they cannot see.
That sounds like the basics of how Qlik works. What's the difference between the association of any table, and the Section Access table?
Perfect. So, to help visualize the mechanics, we have a Qlik data model accompanied by a Section Access table. And all we need to do is associate one field between the data model tables and the Section Access tables. So, in this case we have ‘Department.’ And this would work with any field, right? It doesn't have to be departments; whatever field you want to designate as your security field. And so, in this case, it does work exactly like the associative model. So, then the difference is mainly it's distinguishing between the security table and the application facing data model through the use of the reserve words that I mentioned; that I promised to talk about at least once more through this demo. One of the others that I’ll cover right now is the OMIT; which is used to designate the names of fields that users should not see. So, basically if you're looking at this “John;” he would not see the social security number field. And neither would “Steve.” And so, something unique to Qlik is that you're now you're seeing the benefit of data reduction. That's row level security through associations the way Qlik works natively. And then you're also seeing the ability to apply column level security through OMIT.
Okay. What if I have more than one field that I want to omit.
Yeah. So, that's actually perfect. So, this is what the data model looks like with the security table. So, if Section Access was turned on, the security tables wouldn't be visible in the data model. And they'd be hidden because they're security tables. But one of the things I’m going to cover in this demo is how you can easily test Section Access through the impersonation. What this example is showing you is Section Access is turned off, and that's simply by commenting out the Section Access declaration. And we'll see more of that as we go through it. What I’ve done is: I’ve created an ‘omit group’ and a secondary table to just list all the fields that I would need to omit for different users. So, basically it's a one to many, right? So, instead of having in the example I showed you before: one user and one omit field; this just gives me a secondary table to have that one-to-many relationship. So, if I have three fields that I have three rows in this table per user, as opposed to three rows in this table; now I could do it either way. I could have multiple rows per user for each field in this authorization table that I set up; and this would be my only Section Access table. But I just set it up as a second table just to make it easier to see, right? So, this is this would be one-to-one per user, and this would be one-to-many for all the omit fields.
Okay, and now when you talk about turning Section Access on and off; is that like a setting in the QMC, or how is that done?
That's actually done in the load script. So, you can see here I’ve added a couple screen captures of that Section Access declaration. Any script that falls below the Section Access declaration and before the Section Application declaration is all interpreted as data reduction and Section Access security. So, effectively all I need to do is: comment that declaration. You'll see those two tables are here. With it turned on, those two tables are now gone. This is what the user would see if they were in a published application with Section Access turned on. What I’m left with is this floating island that I use for some user-experience things related to what the users can and cannot see.
So, I understand you've got a demo set up for us. What version of Qlik Sense are you going to be demoing?
I’m actually going to be demonstrating Qlik Sense SaaS. Okay, there are some similarities. There are a couple differences that I’ll cover throughout this, but everything is moving towards the cloud, so I figured why not show that the latest and greatest that that Qlik has to offer.
Yeah.
What we're looking at now is just something that that we have set up it's called ‘sPortal.’ You could actually get it on Github. It's just a way to impersonate different user Access. Three roles that I’m going to demonstrate would be: like, myself; calling myself the CIO. I have Access to all the data. I develop things, I’m a tinkerer, I see the whole entire application, all the data, all the visualizations. The other person I’ll log into this with is ‘Claire,’ who's a marketing lead in the North. And she has visibility into a couple different territories and sales data. And then lastly, we'll log in as ‘Lisa Grisham,’ who is a sales director. And she has visibility into individual rep data in the South territory.
All right. So, here we have the Qlik Sense Hub. And what I’m going to do first is: get into a published copy where the security is already applied, right? So, here I have my published copy which is indicated by this red. This is published to the Everyone space, versus this one which is in my Personal space where I’m doing the development. And that's where I can do my role impersonation. So, we're going to start here.
Okay. Now yeah, can you walk us through this app a little bit?
So, I’ve got a few sheets to help demonstrate the security. I’ve got a Sales Op tab. I’ve got a tab to show the associations and the reduction. I really want to emphasize that the security in Qlik Sense, the Section Access Data Reduction is - it works the same way as the associative model. You're logging in, Sense is clicking on a value behind the scenes, and then it reduces that data set to everything that's related to that value.
Can you tell us what the colors indicate?
So, the OMIT groups that I had designated are encompassing the fields that would be hidden based on your access rights and your entitlements table. Remember that OMIT keyword? The Contact Info group is going to omit Phone and SSN for the users that are in the Contact Info group. If you're in the Office Group, you're going to lose visibility into Office City. And if you're in the Salary OMIT group, then you lose visibility into the Salary field.
All right. So, I’m going to jump into this Sales Ops tab. And as a user that can see everything, I see the total sales for the organization so that's $422,000. Note the logo here. That's going to change when I when I come in and do my testing with Section Access turned off, so I can do some impersonation. And then over here, you're going to notice this is a scatter table that lists all of my sales reps. Right. So, there's a number of different sales reps here. Down below, we have ‘revenue by territory and customers.’ So, these are all my territories. And then I can actually drill through to the different territories. And that's important, because when you see the data reduction, you're going to see how this this table is affected. In one instance, you're going to see it reduce down to two territories. And another, you're not going to see any territories. It's automatically going to be reduced to the customer level data, because a person only has visibility in one territory.
So, this is if we're logged in as an ADMIN, right?
That's right. Yeah, somebody has visibility to the total data set.
Okay.
And then, just as we were talking about the color-coded columns, these are the three that I’m actually applying: it's the Salary, Office City and Phone. That is the main thing here. And I just want to come into this Associations Tab. For those who aren't that familiar with Qlik Sense in the associative model: when I click on a value, all the associated values are in white, and anything that's not associated is grey. So, that's the secret sauce. So, security literally works the same way. So, if I login as a user, and all I can see is New England territory, I’m only going to see data for the city of Newton. I’m not going to see any of these cities. These are going to evaporate, and I would say “before my eyes,” but it would be actually before I even get to see anything. So, obvious that's security, right? I’m not going to see anything related to Reps that aren't in white. All these reps are not in my view, they disappear. But as somebody that can see the whole data set, I can see all these associations across all my data.
So, can we test this with one of the other users?
I’m going to go in as Claire. And Claire is a marketing lead in the North, so Claire has visibility into two territories.
Okay.
And now Claire sees this, right? So, same application but the difference is: with no selections applied, I’m only seeing $212,000 in sales.
Right, that's gone down, okay.
That's right. So, the data reduction is working. I still see all the visualizations; however, this visualization has changed. You might recall, in the previous application, we were looking at a scatter chart. Now we're seeing ‘Sales by Product and Territory-Distribution,’ and that's because she's a marketing manager. And this, products are more relevant to her than a scatter chart of sales reps. So, this demonstrates using Section Access to really drive what visualizations a user can see, right? So, you can do that at the object-level. You can do it at the field-level. You can also do it at the sheet-level. Notice now the territories have been reduced. We had a number of territories at the seven or eight or something like that. Now, we've been reduced to two territories: Canada and New England. Now, I can still drill through, right? And I can still get to the customer level, but I just don't see all the territories that I wouldn't have visibility into.
And I see that Salary field is missing as well.
Exactly right! So, now that green field is gone, because I shouldn't have visibility into Salary Data as a marketing manager. And so, that's it. That's actually data reduction and object-level security at work through Section Access. So, now they go into associations again. That green Salary column is gone, but on the right-hand side of the screen, we can also see that the reps have been reduced. To really emphasize that, let me jump back into my other example as the administrator. Here's all the City data, here's all the Territory data, right? Flipping back over here, you can see that those data is reduced. And I’m not seeing the gray.
Right.
Because I don't have visibility into it. So, that's what the data reduction is doing. It actually is removing that data from the application.
When you have Section Access turned on, does it actually affect the performance of opening the app?
Yeah. So, it could. If you have a very large application, and the reduced data set is much smaller than that, then the perception of the user is going to be: it's taking a, it could be taking a while to open. Effectively you're opening the application if it's large, and then you're reducing it; versus if you had a smaller application from the get-go, that opening time would be somewhat quicker. But and I would say in most cases it's negligible.
To be clear, that's just the first time the app is opened after reload, right? Not every time?
That's right.
And who's the third user we're going to test?
Yep, let's do it. So, the other user now that I want to get in as is Lisa. And Lisa is a sales director. So, she only has visibility into one territory. So when Lisa gets in, now we see a different picture, right? We only see $51,000 in sales. And instead of seeing that distribution chart that we were just looking at, we're still seeing, we're seeing the scatter that we saw originally. But now it's reduced to three reps instead of the whole sales force.
Yeah.
And down below, we're looking at ‘Revenue by a Territory and Customer,’ but it's only the Southeast territory. So, it's automatically drilled down to what territory Lisa can see, and just the customer review. So, that you're seeing what's relevant to Lisa. And over here, we no longer have visibility into the personal information of the employees. You can see that now: you have different levels of access for different users, and different columns are being hidden.
Great.
So, now I’ll go over to the associations to show the difference in what Lisa can see versus Claire.
Okay.
All right. And now you can see a much smaller set of data. You can see much fewer rows, and we're only looking at the Southeast territory now and the city of Raleigh. The reduction is doing exactly what it should be doing. Associations are still working, right? So, I can still see that, but it's only at the level that she has visibility into.
So, how are you able to manipulate the app to show and hide the different charts and fields?
So, let me go back out to my hub here, and go into my unpublished copy that's in my personal space. So, now we're actually opening this with Section Access turned off, and that's that that one Section Access declaration commented out.
Okay.
Instead of that Qlik logo that was in the corner here, I’ve got this this actual drop-down box. So, this is one object that's actually using the show and hides. Hiding the text box with the image in it and it's showing me a list box. And now I have actual visibility into user-level information. So, if I want to impersonate Lisa or Claire or myself, I can. All I need to do is click on these. This is working just like the associative model works.
Right. So, those tables are still in the data model, but now they're no longer Section Access tables; they're just a part of the regular data model?
That's exactly right. They're just regular old tables, right. So, you can see as I click it, I’m seeing the visibility that I would see as if I logged in and everything was being reduced.
So, how do you configure those show and hide settings?
Let me actually get into edit mode. I’ve got some sheets that I’ve duplicated here, and now I can actually edit the sheet and see what's actually driving those show conditions. So, I’ll start with the table here. This is the probably the easiest thing to look at first. So, we've got the Salary field, Office City and Phone. So, the one thing to keep in mind is when you're using Section Access with column-level security, if a column is omitted and it's in a visualization: the visualization won't render. It'll actually fail. You actually have to put in a little protection for that if you're going to omit the field for users that should see that visualization. So, one option is to hide the column or swap it with a different column, or you use a container with different visualizations in it; and I guess the third option would be: show them one sheet versus another. So, I’m going to start here at the field-level in a table, and we'll just look at the Salary expression. Here is your Show Conditions: ‘Show Column If,’ and what I’m actually checking is that OMIT group, the field that I created, and if the OMIT group is equal to Salary, then that means don't show Salary, otherwise show it (-1) is true.
Okay. So, that's how you hide it or show it based on the profile?
That's exactly right. So, just to reinforce that, if I look at Office; same evaluation, except we're looking at the Office OMIT group instead of Salary, right? So, that way when the Office field is eliminated, you won't get an error that the visualization can't render, because the field doesn't exist. You're telling it to disable the field knowing that it's already not there.
That's a great tip for hiding columns with a show condition. I did, I wasn't even familiar with that concept actually.
Yeah. It's actually, it's one of those things that, it's a best kept secret, I guess; which shouldn't be a secret.
Exactly.
So, and then, let's talk about it at the visualization-level. So, in this case, I wanted to drive the marketing manager Claire into a completely different visualization. Data reduction aside, I just wanted to see something else. So, instead of the scatter chart, we use a show/hide container. If those of you familiar with QlikView, it's very similar to that. Here's a Container Object, and the content would be the charts that are in it. So, it's actually the Scatter Chart and the Distribution Plot that we use to show different visualizations based on the access, right? So, in this case the distribution plot. What I’m checking in to see is: if the COUNT of Territories is = 2, then we know that's our marketing manager, and so she should see the distribution chart instead of the scatter plot.
Cool. So, it's a container that has multiple visualizations in it, and you just show it based whichever specific visualization based on the profile?
You got it. Right.
That's super cool.
And then just to tie that off here. Then I clicked on the sheet, and then the last one we have is the show condition for that. So, I’m not using that in this example, but this is something newer that was added so you have that ability. Again, to show different sheets based on whatever conditions you want to create, doesn't have to be security. It could be anything, and the same applies for the other things. I’m just using security as a way to drive show/hide conditions.
I love this concept of turning off Section Access and being able to cycle through the different users to help troubleshoot. Can you walk us through how the script is set up?
Yes. Yes, perfectly. So, the data load editor is what we have to get into, right here. And then I have one tab set up for Section Access. And so, like I was saying earlier, if I want to show my security tables in a data model, all I have to do is comment (//) that Section Access decoration, and now my authorization table and my OMIT fields table become part of the data model so that I can actually select them and impersonate who I want to impersonate without actually having to login as that user, right? And so, you can see this is it. These are my two security tables. I only technically need one, but like I was saying earlier, I created this OMIT group field to then show that one-to-many relationship between a user and the multiple fields that they might need omitted. So, Contact Info is an example: if you're in the Contact Info OMIT group, then you're not going to see Extension, Phone Number and Social Security. The keywords that I was talking about access that's either ADMIN or USER. If you're an ADMIN, you're going to have visibility into all the data. If you're a USER, then the data reduction is going to be applied based on whatever you're using as a reduction field. So, these are both keywords: ACCESS and USER ID. REDUCTION is not a keyword. It's just whatever name you designate for your security key which is going to link to your Application Section. So, this part right here, this Declaration; it’s where your underlying data model fields will begin to load.
Okay.
This link between REDUCTION in the Section Access script and REDUCTION in the data model is really where the actual reduction is happening. If I’m in a REDUCTION of 1, then I’m only going to see data related to Office ID 1. If I’m in 4, then I’m going to see Office ID 1 and 2. If I’m ALL, I’m gonna see 1-5.
Right. That makes sense.
Now, the one thing I want to point out here: ALL is something that I just use to help with the testing. Technically if you are an ADMIN user, you're going to have visibility on all the data. But using this this method of turning off Section Access and being able to test everything; if I didn't have this in here, then then the ADMIN actually wouldn't see everything. So, for testing purposes, you might want to have an IF condition to add these duplicate set of keys for the ADMIN; versus in production, you might want to just use the ADMIN. Does that make sense?
I understand, yeah. You're just recreating the ADMIN rights for data association for testing purposes, but otherwise you wouldn't need it.
Yeah, that's it. That's exactly right. So, that's everything that's behind it.
There's different layers of granularity. How would you manage a more complex reduction? For example: not just Office Location; what if it's Product and Department?
Yeah. So, that's a good question. Well in that case you, would just you would set up a Composite Key. And that actually helps segue into one of the slides that I that I wanted to show.
Okay.
Many of you may have already been working with the load script for a while. So, you might be familiar with star schemas and snowflake schemas and whatnot. I think most often when somebody's building a data model, they just bring in the tables as-is; and they don't create an explicit fact table or a link table, and that's fine. But when you're using security and you have these different levels of granularity; you would have to create a Composite Key for all those values. So, let's just use Department and Product as an example; you would have a field that would have Department (maybe separated by a pipe) and then the Product. And then you would link that into your Link Table. So here you have your multiple fact tables, and so that Link Table is going to operate as a junction box for all your access rights into those facts. So, that way, you're not having to duplicate facts. You're just managing all that through your security table, and so every value that should have visibility into: fact one or fact two, you're managing that here, right? In the same token, you can do that with a Combined Fact Table. This is all precipitated on having a security field that has all the values in your Composite Security Key that you would need to determine what facts you have visibility into and what dimensions you have visibility into. So, that way you're not managing a tangled mess of facts and aggregation. And I’ve seen a lot of different users try to manage this through really complex formulas, and the easiest thing is to create the Link Table when you have complex security.
Okay, that makes Sense. Is there a way so you can set up the same Section Access tables between multiple documents? So, you're sharing the same access across multiple apps?
Yeah, actually. So, you could use what's called an Include Script. So, you could actually store the script for Section Access in a file, in a separate file a text file or a qvs file, and reference that Include statement. Effectively, it's reading the code in as if it was part of the load script, but it's just reading it from a separate file. And any of you that have any web development experience would be familiar with using include files; but it simply is - it's the script that you would use for your Section Access, but you stored it in a separate file. And then, you're just picking that file up and it will interpret that as part of native script.
Just so everyone is aware, we'll include a link with the recording of this session on Qlik community to the same demo app that Mike was using today. So, you can reference that if you'd like. Mike, what are some key takeaways from today?
Yep, so perfect. One thing I promised earlier was: I wanted to cover some of the keywords. So, if you have some experience with Section Access with QlikView, you're familiar with NTNAME. In SaaS, you're using USERID. So, that's one of the bigger distinctions. And there's also a GROUP keyword that can be used in SaaS. There's a couple other things that I’m not going to get into in this, but we'll share this and along with some other resources that'll really get into some of the details. If you're, let's say, if you're coming from Qlik view and you're coming into Qlik Sense, and what changes you might need to consider when you're implementing Section Access in Sense. So, we'll include a lot of links and helpful information and tips and tricks that the Troy’ll package up and put out there for you guys to consume. And I think that should cover most of the things I wanted to touch on.
Yeah, we'll definitely include links to all the documentation where you can find more information and resources. Then it's time for Q and A. Please submit your questions in the Q&A panel on the left side of your On24 console. Mike - which question would you like to address first?
So, the question is: in Qlik view Section Access settings, there's the strict exclusion setting I’ve never understood what the check box does. Can you explain?
So, what that does is it implies that: if there's no values that match the fields you're reducing on, then you actually get to see everything (with strict exclusion unchecked). So, in QlikView you would always want to check that to ensure that somebody who didn't have matching values wouldn't then end up having visibility in all your data. Now in in Qlik Sense, there is no strict exclusion setting, because it's strict exclusion by default, right? So, for those of you that are actually migrating from QlikView to Qlik Sense, that's just one thing to be aware of when you're actually creating your Section Access or when you're doing the migration.
Okay, next question.
All right, let's see, okay. So, I’m using Section Access to limit the Access level the data for each department. Each department chief should only see the data of their department, but for some sheets I want them to see all the data. Is there a way to do that?
So, the sheets themselves don't have anything to do with the data. The data reduction is going to eliminate the data that they can't see. So that's something that you're going to have to determine in your data model: where the security should be applied and what value should be reduced. If the question is: I don't want them to see some sheets, then there's show conditions on the sheets. But if it's around the data, and you truly want to secure the data, then it should be reduced out. Otherwise, you just, you would have to manage it differently.
Okay.
Let's see. So, is it possible to restrict action to certain fields in a table to all users?
I’m not quite sure when we say “restrict action” what we're looking for, or if it's just visibility then. And if we're trying to restrict it from all users, then I just wouldn't load it in the data model. that would be the simplest. If there's for some reason it needed to be part of the data model, then I would use, I would apply that field to the omit keyword, the preserver that is in your entitlements table
Okay.
All right, let's see. So, is there a way to have global Section Access and Section application table that can be applied to multiple documents without having it in the script of each app?
Now that was something we covered when we were talking about “include.” So if you want to reference Include Script with Qlik Sense, you can you can find plenty of help on the community on that or in the help.
And let's see what else we have. So, is there a way to build the Section Access authentication based on their SaaS login, so it automatically limits the data based on who they are without having a separate password for each app?
Yes, that's exactly what we're doing with Section Access. So, we are we're taking that user login based on the subject id, and that's their user; and then they are being reduced based on the entitlements that you've already set up, so you don't actually have to have a separate password for each app.
Okay, next question.
When I develop the app using Qlik Sense locally everything seems to work, but after importing the app on the production server, only the Admin has Access.
I could probably help, but I don't know. I think I need a little more context to answer that. So, there might be some difference in the way, it sounds like there's difference in the, differences in the way that the user is being identified. So, that while it's working locally it's interpreting that USERID is something different, that would be my guess.
In Qlik view, I can use the loop and reduce within publisher instead of Section Access with large QVWs. Is there something similar in Qlik Sense, so that the data in the app is limited instead of limiting Access to the data?
There are techniques to do a loop and reduce. There isn't something specifically the same as loop and reduce in the Qlik Sense scheduler, but there are there are ways to manage that. You can do it through the API is one option. I know that there's a couple other examples out there if you look up “loop reduce for Qlik Sense” you'll see some alternate ways to accomplish that, but I also say the, I mean if it's a concern around the data size, we also have different techniques like “On-Demand App Generation” and also “Dynamic Views.” And what on-demand app generation is just level, is you have an aggregate app, you make some selections in it. It passes those selections to another app which reloads on the fly. And dynamic views is similar, except that you're working with one application, and then certain tables or certain objects are then are refreshing based on the selections in real time, so those are a couple different ways where you wouldn't have to necessarily apply loop and reduce. Kind of a different way of thinking.
These are great tips.
Yeah, thanks. So, let's see what else we have. So, Section Access reducing data on fields of numbers. Does that work or should the format be text in all reduction fields?
It doesn't really matter what the format is, if you have two values that are the same on both ends, then it's automatically going to reduce based on that. So, if it's numbers in one value and text and another value, and a combination of numbers in text, they'll all work if you have a match.
Okay, next question.
Okay, so what are some best practices to reduce access based on multiple field values in the same record line?
Composite Keys ultimately. So, you're gonna when we're talking about the data model, and using a Link Table as your junction box, or a Combined Fact Table, that's how you're gonna have to accomplish that. You're gonna create a Composite Key that ultimately strings together other every value that you want to be a part of that key, and that that is your security right there.
Okay. Can you apply Section Access using dates?
Yep, just another field. It could be a date by itself or it could be a combination of dates, but yeah; I guess that's the, I’d be curious to know a little bit more about how you would apply just a date as security, and what the use case is, but that's, but at the end of the day, it's just another field.
What are the limitations on granting Section Access for a specific sheets in Qlik?
So, that was the Show Condition that I had previously demonstrated in the demo. So, you'll have the ability to show hide the three places. Just to recap, you have it in the object, you have it at the field-level, and you also have it at the sheet-level.
And let's see, what else? There's also: is this available for Enterprise on-prem?
Yes, all our products, you can apply Section Access, except for local copies of Qlik Sense which aren't part of part of the Enterprise deployment.
Okay, the next one: how can I efficiently restrict access over multiple values, and where records are not present one table but are in another?
This is something I’ve encountered before. You're trying to create security on fields that exist in different tables, and so that goes back to that example I gave previously, where you want to use a Link Table. The Link Table solves a lot of problems, because again it is like a junction box. So, you can shove everything you need to in that security field to help drive what's in your fact table. In this case, it sounds like you have ultimately what would be a Combined Fact Table. You have facts coming from multiple tables.
Okay Mike, we have time for one last question.
Okay and let's see. So, is there a standard way to allow a user to see his own detailed data and only summary data for users?
Okay or for other users, I think that's a good question. Because this comes up a lot what you want to do in that case is actually, typically we say just bring everything at the detail level. Because we would then aggregate but if you're applying security, and you need somebody to see the aggregate information then it's not going to work. But what you could do is: actually add the summary data in as separate records, separate transactions, and you could put that in its own table or you could add it as part of your fact table if you're using a fact table
Great! Thank you so much Mike!
Again, thank you for everybody for your time. I appreciate this you know. I love being able to share the things that I’ve learned along the way. Section Access, I know when I first started working with it, just seemed like a black box and there wasn't a lot of information around some of the best practices, and all the things that you could do with it back in 2007 when I started working with it. So, happy to share the things I’ve picked up along the way and hopefully you've gained something from this, and you'll be able to be successful in implementing security in your organization. And so with that, again thank you, and you'll see me on the community.
Okay, great! Thank you everyone. We hope you enjoyed this session. Thank you to Mike for presenting. We appreciate getting experts like Mike to share with us. Here's our legal disclaimer. And thank you once again. Have a great rest of your day you.

maksim_senin · ‎2021-04-16

Great compilation @Troy_Raney , thanx!

STT - Troubleshooting Section Access in Qlik Sense Enterprise

Qlik Sense Enterprise

Qlik Sense Enterprise SaaS

Section Access

Support Techspert Thursdays

Techspert Thursdays

troubleshooting

Troubleshooting Videos