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.
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 the report menu choose "Share" → "Share to team...":
    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 in a self-service manner. You can control what cube members to share; also it is possible to share all cube's reports as well.

  1. Ensure that you have at least one user in your team.
  2. In the cube menu choose "Share to team":
    Team sharing: cube access rule
    NOTE: if "Infer dimensions and measures" is enabled in the cube configuration all cube members are always shared. To choose what dimensions/measures to share it is enough to re-save your cube configuration and keep "Infer Schema" unchecked.

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.