Yellowfin Evaluation Guide

Yellowfin is used for both enterprise analytics and embedded analytics use cases and for building bespoke analytical applications. Use this guide to ensure Yellowfin is the right technical fit for your requirements.

  1. Evaluation Guide
  2. Developing Content
  3. Managing Content in Yellowfin

Managing Content in Yellowfin

  • Content Organization

    Updated 16 June 2020

    It is not uncommon to have many different people creating and editing content at any given point in time, so it is very important to ensure that the right content makes it to the right people.

    Broadly, content in Yellowfin is organized and secured by being placed into a structure of user-defined “Content Folders”. These folders can be used for example to delineate content by business unit (finance, sales, etc) or modularize the content by experience (broad organizational reports vs day-to-day management reports). Additionally, all individual content can layer its own unique permissioning on top of these folders, enabling the construction of highly complex and granular user experiences. <screen-shot of a nicely laid out folder structure>

    In Multi-tenant deployments client organizations can be used to add a second layer to this structure.

    browse content

    Further reading:

    Jump to the section on Multi-Tenancy

     

  • Data Governance & Version Control (In Self-Service)

    Broadly, in a self-service/ad-hoc report creation use case we recommend providing your users or clients with pre-built views that they can leverage and create their own reports on top of. This allows you to abstract a straightforward structure on top of the underlying data, and enforce row-level security while still providing the ad-hoc flexibility you desire. While it is possible to provide clients access to the view level as well, this does assume that data security will be managed at the database level.

    How can I ensure users only use data that’s been approved for self-service reporting?

    In Yellowfin all reports are created on top of views, so only users who have the appropriate permissions to that view will be able to create new content on top of it. This can also be applied to view creation, by placing restrictions at the datasource level.

    How do I ensure only approved content is used by my end-users?

    In large self service use cases there is a strong need to ensure “a single source of truth”. While everyone may have access to financial data, we want to make sure any widely visible financial report contains data we trust to be accurate. For this we can employ “content approval”, where all users are allowed to create their own content, but that content only becomes publicly visible after an administrative user has “Approved” it for use.

    I have sensitive data, do I have to create a new copy of the report for each specific user/group?

    No Yellowfin is designed specifically so that widely shared content only needs to be created once. Data security is then applied to ensure the user’s view of that report reflects their access. <see data security>

    I have clients who want to build their own reports, How can they use what I provide them as a template?

    It is very common to have a set of “power users” who want to take the content framework you have provided them and expand that to suit their own specific needs. Given the appropriate permissions, users are able to “copy” pre-built reports or views and modify these to suit their specific needs.

    How do I manage versioning in self-service?

    In self-service use cases it is often not practical to rely on a multi-environment workflow to manage report development (see content migration) . For this, Yellowfin provides several features within the application to help manage report versioning.

    Content In Yellowfin is never truly deleted. Yellowfin maintains a record of all previous versions of content in its configuration database. This allows us to provide the ability to easily undo changes made to reports, dashboards, and views. For simple in-application versioning, you can utilize the “copy” feature, saving each report with a date-distinctive tag.

    Further reading:

    See Data Security

  • Content Migration

    Can I migrate content from one instance of Yellowfin to another?

    A typical Yellowfin deployment will consist of at least two environments. One for production that end users work in on a day to day basis, and one or two that closely mirror the production environment but serve a development or staging role. Once content has been created in the development environment, it is migrated into the production environment using Yellowfin’s Import/Export functionality.

    content migration export

    What options exist to migrate content?

    When importing content, you are provided with several options to customize the process, allowing you to define how the content is treated within the new environment. Examples of this include:

    1. Adding newly created content
    2. Replacing a current report or view with an updated version
    3. Adjusting the datasource connection used by a view (you did all your work on your dev db, now you want that report use the client db)

    content migration import

    How do I integrate with my dev-ops workflow?

    Yellowfin import/export files are stored in XML format and can be easily stored in repositories such as GitHub to easily integrate with current dev-ops workflows.

    This process is also able to be fully automated using Yellowfin’s Administrative Services.

    Can my users author new content in production?

    For enterprise and self service use cases it is common to allow your end users to do ad-hoc report creation in the production environment. For this Yellowfin offers an Approval Workflow, ensuring that only reports that have been verified and vetted are able to be seen publicly