Once the Qlik Sense server is deployed, perform the following steps:

This is obvious if you look at the app overview in the hub. Here, you now have two rows of sheets: one with sheets that are fixed and public, and another with private sheets that aren't visible to other people.

You can also see this difference on the sheet listing the app objects. This sheet lists all sheets and stories, and QMC clearly indicates whether an object is public and who the owner is.

The user who creates an app is automatically designated as the owner of the app and its app objects. The app objects are published when the app they belong to is published. However, the users can add private app objects to the apps and share them by publishing the app objects from Qlik Sense. When this is done, the app overview in the hub gets three rows of sheets, as shown in the following screenshot:

As soon as you want to manage the Qlik Sense server in terms of ownership and access rights, you need to have your users defined. Normally, these are already defined in a user directory, for example, in Windows Active Directory. Hence, you want to reuse these definitions.

On the User directory connectors page, you can define several sources for your users and user groups. You need to do this and sync at least one of them before you can start distributing licenses and access rights to your user groups.

The users are managed on the Users sheet. However, when you first start Qlik Sense, the list of users is fairly short: just you and a couple of system users. To populate the list of users, you have two options:

Once you have created or imported an app, you may want to publish it. Publishing an app means that you move it from your personal workspace to a stream of your choice.

You have already seen the streams in the hub, where they appear to the left as groups of apps. My work is your personal stream that no one else can see.

Streams, as seen from the hub

An app can be published to only one stream. By default, Qlik Sense includes a stream called Everyone, and you can create any number of additional streams from the Streams sheet. You should most likely create one stream for each distinct user group. Use the Create new button in the upper-right corner of the screen.

When creating your stream, you have the option to add a security rule, making the stream available only to some users. This is a very important security feature. One obvious example is if you have a set of apps that should be seen only by the Human Resources department. Then, you should create a stream for this group and use the user information from the directory service to give access to this stream.

Another common case is if you want to delegate the administration of a stream to a group of users. The following screenshot shows a security rule that grants access to the Human Resources stream and to all users belonging to the HR user directory:

Connectivity means the connection to source data. Source data can be ERP systems of different kinds, file folders, web addresses containing tables, and so on. When running a Qlik Sense script, data is pulled from the different sources into the Qlik Sense app, so that it can be analyzed at a later stage.

With Qlik Sense, it is easy to get an overview of all data connections used, something that used to be a challenge. By opening the Data Connections sheet, you get a list of the data connections used in the different apps.

The data connections can be managed and security can be set separately for the different connections. It is, for example, possible to prevent some users from using a specific data connector. This way, you can control the usage and ensure that data is used in the correct way.

On the Tasks page, you define the jobs that need to run in the background. These are of two kinds: reload tasks and user synchronizations.

The reload tasks are necessary to refresh data in the apps, which means that you need to set up tasks so that they are refreshed with the frequency you want. Most apps should be refreshed once a day, but some others only need to be refreshed once a month. There are both advantages and disadvantages with a frequent refresh of the data. If it is refreshed rarely, for example, once per month, the users will not have the latest data.

On the other hand, if you refresh data too often, such as once per hour, you will have a heavy load on your server handling the reload tasks. You will also create a situation where two users in a meeting may have different opinions about what the correct number for a specific KPI is, since they looked at two different versions of the app. One looked at the app an hour ago, and the other just 10 minutes ago. This does not create an understanding; rather, it creates confusion, since you have two "versions" of the truth.

You should ask yourself if the users benefit most from having as fresh data as possible, or if they benefit more from having "one truth". A good balance is to have one refresh per day. The users will learn this, and refer to the numbers as "today's numbers" and "yesterday's numbers".

User synchronization is necessary to refresh data from the directory service, so that Qlik Sense is aware of any changes made to groups and users.

A task can be triggered by either a scheduler or the completion of another task. This way, you can get task chaining.

The group to the bottom-left in QMC relates to system settings. Here, you can configure the nodes, engines, proxies, schedulers, repositories, sync rules, and certificates. With these, you can configure how the Qlik Sense server would work on different computers. You can do really advanced things here, but this is outside the scope of this book.

You can set access control for most of the preceding settings, for example, only some users should be able to see a specific application; only some users should be allowed to use a specific data connection; all users should be allowed to create data connectors to databases, but not to file folders; only some users are allowed to log in using a specific pool of login access passes; and so on.

When doing so, you should think of the following user types:

These rules are called security rules, even though they do not always pertain to true security. They can be edited on each sheet, for example, the rules for streams can be edited on the Streams sheet, but there is also an overview: the security rules have a sheet of their own.

When you create a security rule using the basic interface, you create a property-value pair that grants users the right to do something. In the preceding screenshot, all users are granted the right to create data connections that aren't file folders.

The rules are property-based and the properties are used to describe the parties involved in an access request. In the usual case, the parties involved are the user making the request, the environment the request is made from, and the resource the request applies to.

Each property is defined in a property-value pair such as group = Sales or resourcetype = App. Each request, in turn, includes the property-value pairs for the users, environments, and resources involved in the request together with the action that the the person making the request wishes to perform on the resource, for example create, update, or delete.

The four components in security rules: user, environment, resource, and action

You can create rules based on the property-value pairs. This means that requests for an action on a resource are granted only if the property value of the requester matches the property-value conditions defined in a security rule for that resource.

A rule can read as a sentence in the following way: Allow the requester to [action] the [resource] provided that [conditions].

Each rule must describe the action and the resource or resources the action should be applied to. If you don't define any rules for a resource, no users will have access to that resource.

By design, security rules are written to include, not exclude, users. Users who are not included in security rules will be denied access. So, security rules must be created to enable users to interact with Qlik Sense content, data connections, and other resources.

Hence, the rules define when access is granted, and there is no rule that can deny a user access. If there is a rule that allows the user to do something, they are allowed to do so. So if you want to deny a user something, you must delete the rule that grants access, or edit the rule.

Delivered together with Qlik Sense, you will also find two monitoring Qlik Sense applications: License Monitor and Operations Monitor. These read the logfiles of Qlik Sense and will give you a good overview of the state of the Qlik Sense server.

The following screenshot shows Operations Monitor:

Operations Monitor

The following screenshot shows License Monitor:

Lincense Monitor