This documentation page assumes that you already have a SeekTable account. Create your free account by signing up.

Reports Sharing in SeekTable

Let's assume that you successfully configured your data sources and saved some useful reports. What is next? Real impact of business intelligence reveals when you share your insights with others, when your reports may affect their business decisions. With SeekTable you may share reports in the following ways:

Exports
any report can be exported to PDF/Excel/CSV file that you can send to your audience.
Pros:  old-school, time-proven way to share reports.
Cons:  file is a data snapshot and quickly looses actuality. Users need to have a file viewer. No interactivity: viewers cannot modify the report. You cannot control who has access to the file.
Reports generation and delivery may be automated via API. With share by email API its easy to send hundreds of parameterized reports by email with a simple shell script (that can be executed on schedule).
Publish to web
saved report can be published to web and accessed with a public link (or embedded via iFrame).
Pros:  viewers always get actual data: no need to re-send new exported file or refresh reports manually. Report can be viewed from any device with a web browser. Viewer can sort/filter/export report data (if your account has advanced publishing/embedding features).
Cons:  Anyone who knows the link can access the report (secure embedding is supported in on-premise SeekTable). Users cannot customize your report and save their own version for future use. On cloud SeekTable content is cached for 15 minutes (free accounts) or 5 minutes (accounts with advanced publishing subscription).
Team sharing
reports can be shared with other SeekTable users. More than this, you can even share your cubes and allow others to create/save their own reports based on your cubes (they will not able to see/modify cube's connection details). This feature requires a paid subscription (only for the user who shares reports); you can evaluate "Team sharing" capability with a free 14-day trial.
Pros:  Secure way to share your data with your team or clients: only users who have access to the report can view it. Maximum interactivity: viewers can use all report designer options (you can control which ones are allowed). Users can subscribe to shared reports to receive emails with reports on schedule.
For shared cubes: viewers can create their own reports (you can control which dimensions/measures/parameters are shared).
Cons:  Viewers need to have (free) SeekTable accounts to access reports shared in this way. Login-less access is possible with embedded app view.
Next sections assume that your SeekTable account has "Team Sharing" subscription.

How to share a report to team

  1. Go to "Team" section (top-menu) and then "Team Members" where you can invite users into your team:
    Team sharing: invite team members
    NOTE: in a self-hosted SeekTable invites are not used and confirmation is not needed to add users into the team.

  2. In report's menu choose "Share" → "Share to team...". If this report already was shared previously (has sharing rules) it navigates to the list of cube's rules; otherwise, a new cube sharing form is opened:
    Team sharing: report access rule

Users cannot save any changes for shared reports and they can select only dimensions/measures that are used in these shared reports. You may allow them to clone a shared report or create their own reports based on shared cubes as described below.

How to share a cube (dataset) to team

By sharing a cube you can allow users to create & save their own reports based on your cube in a self-service manner. This is a secure way to share your data with others: team members cannot access neither underlying dataset (database) nor sensitive cube configuration things like connection string or SQL query.
Technically sharing is controlled by an access rule which has options that affect what exactly is shared and to whom. You can share your cube just in a few clicks:

  1. Ensure that you have at least one user in your team ("Team" section).
  2. In cube's menu click on "Share to team...". If this cube already was shared previously (has sharing rules) it navigates to the list of cube's rules; otherwise, a new cube sharing form is opened:
    Team sharing: cube access rule
  3. Sharing rule has the following options:
    Option Description
    Share To Share this cube to all team members or choose concrete members or groups.
    Granted dimensions Share all dimensions or a concrete subset. Note that when reports based on this cube are shared via own sharing rules, dimensions that are used in these reports are added to the "granted" list implicitely.
    NOTE: if cube's "Infer dimensions and measures" is enabled all cube members are always shared (as they are determined dynamically) and it is not possible to choose which dimensions/measures to share. If this is the case, you can go to the cube's configuration form, keep "Infer Schema" unchecked and save the form.
    Granted measures Share all measures or a concrete subset. Note that when reports based on this cube are shared via own sharing rules, measures that are used in these reports are added to the "granted" list implicitely.
    Granted parameters Allow to use all report parameters ("Params" tab) or a concrete subset. This restriction affects all shared reports based on this cube.
    Granted actions Additional actions that are allowed for shared reports based on this cube:
    • Give up the ownership: users can create own reports based on this shared cube and then move them to the cube's owner. If cube's sharing rule "Share all" option is enabled, moved report is shared automatically (according to "Share To" settings). Cube's owner gets email notifications about all moved reports (login email address is used).
    Cube reports Sharing rule may affect cube's reports:
    • Share all: all reports of this cube are shared with default report sharing options. If some reports have own sharing rules (or affected by workspace sharing rule) they are shared according these specific rules.

How to restrict record access / row level security

Row-level security (RLS) enables you to restrict users' access to specific rows of data based on predefined criteria or rules. With built-in RLS capabilities you can ensure that users see only the data that is relevant or permissible for their roles. For example, with RLS it is possible to share the same report (or whole cube) to many customers and display only their company's data.

In SeekTable access restriction logic is applied on the database level in the form of special conditions included into the query. Technically records filtering is based on a special parameter that represents the user's identity and it is guaranteed that users are unable to affect or modify this special parameter in any way.

When reports and cubes are shared inside SeekTable app via "Team Sharing" capability RLS logic may be based on the user's login email:

  1. go to "Edit cube configuration" form of the cube where you want to configure RLS.
  2. scroll to "Parameters" section and check Enable "seektable_user_email" parameter option.
  3. now you can use a special parameter seektable_user_email to filter records as you need in the database query. It always holds SeekTable's user email who accesses the report.

In addition to seektable_user_email you can define your own parameters (like company_id or client_id etc) and then assign group-specific values to these parameters:

  1. go to "Edit cube configuration" form of the cube where you want to configure RLS
  2. configure a parameter (or several ones) and use it for records filtering in the cube's query. Report's owner (creator) can use this parameter in a usual way to choose a filtering criteria (to test this report for the concrete user's group, for instance).
  3. go to "Team" section and create groups for users (or edit existing ones). For each group you can define group-specific values for parameters that are used in cube's RLS logic.
  4. share reports / cubes and choose these groups in "Share to".
  5. now when a user (that is memeber of one of these groups with overrides) opens shared reports it will be filtered according to hardcoded parameters. If user belongs to multiple groups overrides are merged.