Back to Project
Installation and Resources
- Pre-requisites
- Install and Activate Yurbi
- Setup a user-friendly URL
- Explore the Demo Environment
- Change your Yurbi admin password
- Join the Yurbi Community (and other resources)
- Backup Strategy
Connect Yurbi To You Data
Security Planning and Setup
- Security Planning
- Folder and Report Security Groups - Simple Environments
- Folder and Report Security Groups - Department Environments
- Setup Data Security Groups
Report and Dashboard Building
- Report Building Planning
- Out of the Box Visualization Types
- Build Datagrid Reports (Detailed and Target)
- Build Summarized Reports
- Drill Down Reports
- Build KPIs Reports
- Build Chart Reports
- Linking Reports - Data Blending
- Advanced Reports
- Build Combo Charts
- Map Visualizations
- Using SQL Stored Procedures
- Create Dashboards
- Create Filters and Saved Views
- Dashboard Smart Filters
- Configure Dashboard FastCache
Deployment and Training
- Apply Your Branding
- Create Data Tag
- Create App Shield Security Policies
- Create Users
- User Training and Documentation
- Provide Access To Your Users
- Display In Unattended Mode
Operations and Maintenance
Setup Data Security Groups
Lastly, we want to set up the 4th layer of Yurbi security, data-level security.
If everyone on your team has full access to all the data in your reports and dashboards, then you can skip this step.
However, if you are using Yurbi for embedded analytics for customers or have segments of users with a specific “need to know” access level, such as managers who can see everything versus normal users who can only see their own information, then data-level security is going to be necessary.
Instead of having to copy and edit reports for each data level of security, with Yurbi, you configure a data-level security policy and Yurbi dynamically applies “need to know” security for each logged in user.
We normally recommend the following setup to enable data-level security:
- Set up a data-level security group for each segment of users that need a restriction on the amount of data they should see.
While it is not necessary to create a specific security group just for data security, we recommend that you do, and that you give it a prefix or naming convention so it is clear, this group is only for data security.
- Create a Data Security Policy for each segment of users that need a restriction, assign the proper group created above.
So in a multi-customer environment, each customer would have a data security group, and each customer would have a data security policy. There is a one-to-one relationship.
Best Practices:
- Users should be in no more than 1-3 data security policies. Each policy adds execution time to queries. Add too many and your users will suffer waiting for report results. This is why we suggest creating a specific data security group outside of your Folder/Report security groups. That way a user can be in lots of folder and report access groups but have all their security constraints in a dedicated data-level security group.
- Use a naming convention to clearly identify security groups. Then teach your report builders and library folder admins to not use those groups as report or folder groups.
- In your data security policies, be sure to create a data-level constraint for all report types in a Yurbi App. If a user has access to a Yurbi App, they have access to all report types. If a constraint is needed on one, it’s probably needed on the other report types as well.
In this video, we walk through a scenario of setting up multiple data security groups and policies as an example.