Page History

When to use

Use if you wish to limit access to certain functions – such as the ability to write reports

When not to use

Roles cannot be used effectively to limit access to information and data.

Benefits

Easy to maintain for all users.

Tips

Limit the number of roles created at your organization. By increasing the number of roles the level of effort required to manage access increases. Generally only permit a single role per user. Although Yellowfin does support multiple roles it can lead to confusion in a business user.

When to use

Use folders to create meaningful business groupings for reports.
If your views are ‘write’ secured then providing access securities to folders allows a user to publish sensitive reports into secure folders for wider but secure read only distribution.

When not to use

Folder security is meaningless if users can write reports against a specific view (i.e. it is unsecure) but cannot see a folder in which that view logically fits.
For example the Folder may be HR reports and the view is a view to the HR database.
If a user can write reports and the view is not secure then whether there is security on the folder is largely irrelevant since the user will have access to the base data through report builder.
If all your sensitive views have READ level access defined – applying security to your folder is not required.

Benefits

Folder Security is excellent for locking read only users out of specific subject domains.

Tips

Create Subject domains that are intuitive for users to understand.
For example Executive HR – this folder can then be made exclusively available to Senior Management for HR reports.
Users publishing reports into folders must be aware of the security attached.

When to use

Use if you have multiple view administrators – each of whom require access to specific source databases only.
Use if some users have free hand SQL access to write reports and the data in the data source is sensitive.

When not to use

Do not set security on the source in an attempt to limit access to drag and drop report writer users.

Benefits

It is easy to maintain for a select number of users.

Tips

Limit the number of users that have administration access to views. Especially if they wish to edit the same source system.
Multiple administrators can lead to contention issues when managing views.

When to use

Use if you wish to limit users that have access to the report writing function using the specified view.
Use if you wish to be specific in defining which users can read reports created by a specified view but are not permitted to write reports.

When not to use

If reports in the view are to be written by a handful of users and then published to a wider community it is preferable not to use READ level security. Use category access for this.
For example even though the HR view contains sensitive data the HR report writers must write and distribute many reports from this view – most of which do not contain sensitive data.
Simplify security of the view by having secure categories into which the report is saved rather than managing security in both the categories and the view.
If the data contained in the view is not sensitive then do not apply security to it.

Benefits

Easy to maintain for EDIT level security – can become complicated if using READ level security in conjunction with category security.

Tips

If the view is sensitive determine who the users writing reports against the view are and for whom they are writing reports. Use this to determine the best security strategy for the view. If the reports are for a wide distribution view security for read access might not be appropriate.

When to use

Use if you wish to create a general view available to many users but restrict access to sensitive data to only a few users.

When not to use

Do not use if the view in general and the columns all have the same users that can access them.

Benefits

Can be used to secure specific columns within a view.

Tips

This is a difficult security option to maintain from an administration point of view. Consider alternatives first.
Only users with access to the view will be able to have column level access.

When to use

Use if you wish to create a general view available to many users but restrict access to data based on a users relationship to the data – e.g. cost centre managers.
This mechanism is very good for creating Privatised reports. By using value based filters you can create a single report which is distributes to many users. Each user will however, only see their specific / Privatised data.

When not to use

Do not use if the view in general and the columns all have the same users that can access them.

Benefits

Can be used to secure data within a view to only display relevant data.

Tips

This is an easy option to maintain from an administration point of view.
This mechanism allows you to provide access to all data within a view to all your users with the security of knowing that they will only see their specific data.